rns.recipes

I've significantly reworked and improved both the storage backend and memory handling in RNS, including how all the major transport tables are handled. A new SQLite-based, managed (and fast) storage backend is now the default, and replaces the file/directory based storage for most things. I'm transitioning a few things at a time, though, so some parts are still on directory-based storage. If for some weird reason the standard-lib sqlite3 module is not available, or not working, RNS will fall back to the old storage backend, so even the most weird and esoteric systems should still run it just fine.

Additionally, this will be the first release that starts treating path tables as distributed across the networks. The amount of destinations have grown significantly, and it's no longer feasible for every single transport node to attempt to hold every single destination in memory (well, larger systems still wont have any problems, but embedded devices and such are getting hammered a bit now). Actual path usage is now being tracked, and tables are being culled more intelligently based on that. The immediate net result is that processing and memory load will decrease. The long-term effect and goal (which still needs a bit more work) is that path table sharding will start to form emergently across the network, and transport nodes will automatically learn what paths actually makes sense for them to keep.

Furthermore, non-transport nodes now much more aggresively cull unused destinations from tables, and this greatly reduces memory and processing load on non-transport devices, user-facing applications, appliances, et cetera.

Even further more, a new memory management system has been implemented, that tracks heap usage over time, handles garbage collection and eviction much more intelligently, and cuts long-term memory usage by about 50% for heavily loaded transport nodes.

If you want to help test this, I have just pushed the latest source version to Aleph. Any testing and feedback, especially from node operators would be much appreciated.

Please note, that to see memory improvements immediately, you will probably have to wipe your path table and known destinations storage files before first running 1.6.0. Otherwise, things will get culled out eventually, but it will happen slowly over several days at first (it's intentionally a bit conservative here).

Also, it's probably a good idea to take a backup of your .reticulum directory before running it. On first run, all the relevant storage will be migrated to the new storage backend, and Lord knows I've tested this like some kind of manic, but there's bound to be that one system somewhere where something goes wrong. If you're the one who finds the bug, I owe you a beer!

Also, if you have any questions about any of this, post them here.

Oh, for the immediate memory benefit, you need to wipe the tunnels table as well.

200% based. sqlite3 kicks ass

Perfect timing! I had just been looking into memory consumption on iOS. There might be some possible memory optimizations in Resource.py as well, but I haven't verified myself yet.

Thanks Mark!

Would it be a good idea to add a per-interface exemption for the never used path culling, both the linger timer and paths that are never used when the advertised interface bitrate falls below a certain threshold like 8 kbps?

Paths learned over slow LoRa or HF radio are expensive to relearn and the cost also compounds when there is any amount of packet loss. The idea would be to retain the paths until their normal expiry when they were learned over an interface below the bitrate threshold.

RNS 1.6.0 up and running on my transport node. Works as advertised. Memory usage dropped significantly. I will keep an eye on it tonight. Thanks.

@Zenith: Yes definitely, that's more or less a must, actually. Thanks for pointing it out! Might be a good idea to simply set the used timestamp on such paths so they persist as soon as they arrive.

Running stable version of NomadNet on RNS 1.6.0. I have started to get these messages in logs, I don't remember ever seeing them, so posting them here in case they are useful:

[2026-10-29 20:32:51] [Info] Starting user interface... │
│[2026-10-29 20:33:01] [Error] Could not flush known destinations to storage. The contained exception was: NOT NULL constraint failed: known_destinations.packet_hash │
│[2026-10-29 20:33:11] [Error] Could not flush known destinations to storage. The contained exception was: NOT NULL constraint failed: known_destinations.packet_hash │
│[2026-10-29 20:39:23] [Warning] Running stamp generation on darwin, work limited to single CPU core. This will be slower than ideal.

Running on Mac Studio with Apple M4 Max processor. I don't see any change on user experience.

@zugzugNL are you still getting that error if you update to the latest source version from Aleph? You might have to delete your known destinations database (~/.reticulum/storage/known_destinations.db*), but try first without doing so.

Never mind @zugzugNL, there is a bug here. I have a stupid schema assumption that is actually wrong, and that's what is causing it. Thanks for spotting and reporting it! I'll have it fixed shortly :)

Glad to be of assistance, Mark! I really appreciate the effort you put into this.

Reticulum 1.6.0 – promising performance improvements on Milk-V Duo S

Hi Mark,

After approximately 18 hours running RNS 1.6.0 on my solar Milk-V Duo S (512 MB RAM), with LoRa, Yggdrasil, an Internet backbone connection, LXMF PN and NomadNet, RRC, the results look very promising.

RNS 1.5.7: ~~150–170 MB RSS, ~~25–35% CPU.

RNS 1.6.0: ~~40–43 MB RSS, ~~4% CPU.

Current database: ~~2,230 known destinations and ~~2,270 cached announces.

Important: RNS 1.5.7 had significantly more stored destinations and announces (10K+), even after a similar runtime, so the memory figures are not directly comparable.

The much smaller database suggests improved filtering or cache management.

So far, 1.6.0 looks very promising. I'll continue monitoring it as the database grows.

Thanks for the great work!