New Hybrid Lokinet/Tor Gateway - Check the config and details >>here<<_

Thanks to SkyGuy's SOCKSClientInterface_ , everyone can route his/her reticulum transfers through a tor exit node.

This, however, usually needs the user to modify the tor config - it can be troublesome in certain circumstances.

To bypass this and to add an extra layer of anonymity, I came up with the idea of the so called ToReticulum Gateway!

(By the way, I just realized others joined the club! Welcome on board, RUHR-⚒-RETI | Tor-GW and NL-WB Backbone! Glad to see others building on the torified gateway concept. If you need any tips on security hardening or architecture to keep your peers safe, the door is open.)

If someone connects to the torified server interface, all the traffic, all of the data will be transferred through TOR, connecting to clearnet via a random exit node.

This is a double-torified system: the gateway accepts incoming connections exclusively through the Tor Hidden Service (through the .onion address), AND it strictly routes all outgoing data to the rest of the Reticulum network through Tor exit nodes as well. (via the SOCKSClientInterface)

All traces and routes will be invisible to clearnet, as the gateway communicates with the other gateways only via one or two tor-exited gateways.

So it doesn't know who connects to it, and the connected gateway will only see the random tor exit node's IP only - the traffic will be anonymized.

To maintain anonymity the Gateway also does the following methods:

1. Requesting new tor identity - regular basis

2. Tor daemon restart - occassional basis

3. Reticulum restart with automatical backbone rotation - occassional basis

4. Reticulum, tor shutdown with reticulum storage wipe - a few times daily

Thanks to Reticulum's self-healing ability you will probably experience just a sudden delay, in worst case scenario the delay can be up to 5 minutes - that usually happens during method 3.

You don't need to do/restart anything, just wait till the connection establishes.

You need nothing else but to download SOCKSClientInterface.py from SkyGuy's Repo_ (if you have access to the web) or here_ via reticulum.

After inserted it into the custom interfaces folder (usually the ~/.reticulum/interfaces/ in Linux), you must edit the reticulum config file in the following way:

[[Toreticulum]]

type = SOCKSClientInterface

enabled = yes

target_host = edz422kobqpb6tgny6rdvdky5cdrnh5dnzmnn6c2twwebvomk2fdgxyd.onion

target_port = 4666

proxy_host = 127.0.0.1

proxy_port = 9050

Be aware that it is possible that on certain platforms the "[[Toreticulum]]" has only one bracket in the interface's name, add a second if this problem persists.

Do NOT modify anything else, except the tor proxy port - doublecheck what your TOR uses, for example the Tor Browser uses 9150, in the case of the tor daemon is 9050.

It shows nothing more but something than this:

tcp 0 0 127.0.0.1:4666 127.0.0.1:8438 ESTABLISHED 661100/python

or

Inbound:

BackboneInterface[Tor Inbound/127.0.0.1:4666]

Status : Up

Clients : 1

Mode : Gateway

Rate : 1.00 Gbps

Traffic : ↑10.78 KB 1.97 Kbps

↓16.35 KB 3.27 Kbps

Outbound:

SOCKSClient[Tor Outbound]

Status : Up

Mode : Full

Rate : 10.00 Mbps

Traffic : ↑674.37 MB 0 bps

↓45.46 MB 6.59 Kbps

Easy, simple, efficient.

1. It is highly experimental right now, so expect some hiccups here and there.

2. If you want full anonimity connect to ONLY THIS GATEWAY and nothing more - the gateway will do the traffic and discovery.

3. If you wish to use nomadnet, meshchat or sideband, I recommend to use propagation all the time you want to send a file, as with direct method, it can cause hiccups.

4. Speed will be variable, but prepare yourself that it can be really slow - it is good for communication, sending texts and small files, but anything above 20MB will be slow.

5. If you want a fully torified client, I recommend to start from the scratch, delete all existing reticulum data, especially the storage folder.

I tested it on Windows and Linux so far, feel free to give feedback on other platforms.

Of course I can mention it if I must that if you don't use the TOR daemon, open and don't close the tor browser while you are using reticulum.

This is a one-link gateway right now, planning to do a three-link and a mixed one.

If you have questions, trouble to connect and want give feedback, just contact me.

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

Changelog

v0.8.4 (2026-08-01)

* Kargo and the ToReticuLoki Gateways are stable.

* The lightweight, fault-tolerant rncp-based filetransfer program that tries to endure all types of network and blackouts being written.

v0.8.3 (2026-07-25)

* Raised the timeout to even higher: 600 seconds now for the 'Kargo propagation node.

* After some testing, it is clear that you don't need to use propagation all the time, and the speed can be relatively fast, especially between ToReticuLoki gateway users. The only risk is sending large files (reticulum-wise), as the ever-changing nature of the Gateways can cause disconnects and timeouts and pathfinding/routing problems.

* After some further testing, the conclusion is that if two clients are connected to the ToReticuLoki Gateways, it is entirely possible to send up to 50MB sized large files through nomadnet/meshchat(x) while using the Kargo propagation node. Speed can reach up to 5-6 Mbps, especially if you are connected to ReticuLoki Gateway and use Nomadnet for the upload. (Somehow Meshchat(x) seems to be slower).

* Receiving extra large files (20MB+) can be problematic while using the Kargo and Meshchat(x), as timeouts can happen, and it seems that the timeout option can't be modified for this app. It can be squeezed through with huge delays, but it is really like a coinflip. (It seems to be fine on Nomadnet - didn't test with mobile apps yet). To deal with this, an upcoming, minimalistic program built on rncp is in progress.

v0.8.2 (2026-07-23)

* Temporarily raised the Kargo timeout to even higher - 180 seconds. Hopefully this will marginize timeout errors.

v0.8.1 (2026-07-22)

* Temporarily raised the Kargo timeout to 120 seconds after noticing frequent timeouts in the logs. It seems to improve overall connectivity and the distribution factor.

v0.8 (2026-07-15)

* Re-enabled autopeering of ToReticuLoKargo as it is needed for healthy integration of the propagation network. Instead of choosing nodes as statis peers, to find a solution of getting rid of "undead peers" I rather implemented the Exorciser along with the Summoner.

* The Summoner protocol forcefully synchronizes all the long non-synced peers after an amount of time - often

* The Exorciser protocol forcefully break peerings with unreachable, long unseen peers - regularily

* The Resurrector now (rarely) deletes the peers file from the lxmf folder, but due to the autoannounce of the propagtion node, the peers will find the way back to the 'Kargo soon or later.

* All the anonymization scripts are now rewritten python, all of them became modular and customizable, instructed by the Ouroboros orchestrator.

v0.7.1 (2026-07-11)

* Disabled autopeering for ToReticuLoKargo. This eliminates the fatal synchronization loops and zombie peers caused by the Shuffler/Wiper protocols breaking torified clearnet tunnels, completely wiping out past message timeouts.

v0.7 (2026-07-11)

* ToReticuLoKargo Tor/Lokinet-encapsulated Propagation Node is introduced on its own page

* The anonymization protocols are become labeled as Sneaker, Shuffler, Wiper, Resurrector, Rebirth (will elaborate them in the future)

* New main page is being written.

v0.6 (2026-07-05)

* Minor cleanup of the scripts' code, planning to rewrite all in Python.

* Now the ToReticuLoki Gateways use four outgoing torified exits, connected to geographically distinct gateways.

* Implemented the Shuffler - more than 120 backbones are in the database, grouped by geographical locations. Each time Reticulum restarts, it randomly chooses 4 new gateways, ensuring the currently used ones are excluded from the draw.

v0.5 (2026-06-30)

* Renamed the whole project to ToReticuLoki, the ToReticulum/ReticuLoki names only resemble the nature of the gateways.

* Created a codeberg repo_ for a clearnet point for the project, if the project reaches version 1.0, I will upload all the configs there.

* Posted the gateway of RUHR-⚒-RETI | Tor-GW and NL-WB Backbone who seems to have implemented the concept.

v0.4 (2026-06-24)

* Implemented new tor identity request - regular basis

* Implemented tor and lokinet restart - occassional basis

* Implemented reticulum, tor and lokinet restart - now semi-manual, but later: automatical backbone rotation

* Implemented reticulum, tor and lokinet shutdown with reticulum storage wipe - very few times daily.

v0.3.1 (2026-06-19)

* Experimental multi-docker solution for further anonymization being tested. Weighting the cons and pros.

v0.3 (2026-06-17)

* ReticuLoki's own page is online.

* Provided clarification and proofs of the gateways' double-blind, zero-trust nature and its connection methods.

* New main page is in progress.

v0.2 (2026-06-16)

* Changed onion address, hosting the Gateway in a more isolated/secure environment.

* ReticuLoki Gateway is online, ready to accept peers (detailed description is in progress)

* Restructuring/updating main page is in progress.

v0.1 (2026-06-13)

* Initial release of ToReticulum Gateway concept.

* Added full support for SkyGuy's OCKSClientInterface

* Published blind onionHidden Service architecture details.

* Experimental Gateway is online, ready to accept peers.