rns.recipes

This release adds live interface attach, detach and reload, as well as significant improvements to interface discovery. Auto-connecting interfaces is now also supported on Windows and macOS.

It also brings improvements to rngit and fixes discovered I2PInterface configuration snippets, along with a number of other bugs.

Changes

• Added ability to --attach, --detach and --reload interfaces to the rnstatus utility
• Added interface discovery auto-connect support on Windows and macOS
• Added ability to download micron-converted versions of markdown files to the rngit page node
• Added workdoc counts to filter scope links to the rngit page node
• Added version info to rnstatus discovered interfaces output
• Added --show-stale and --show-unknown options to rnstatus
• Added sequential naming of auto-connected interfaces on announced name collisions
• Added auto-connect implementation and version criteria filtering
• Added configuration option for allowing auto-connects to discovered interfaces with missing version info
• Improved sanitization of nonsensical interface discovery IFAC announce data
• Fixed I2PInterface discovery config snippets not including .b32.i2p
• Fixed timeout and response rejects not being processed for single-packet requests, by JRG
• Fixed missing configurable property propagations on spawned interfaces, by JRG
• Fixed ingress control producer comprehension at mid-watermark using incorrect variable name for interface type check, by JRG
• Fixed instances of announce_cap property ensurance logic not storing announce cap value as a fraction, by JRG
• Fixed a potential race condition in LocalInterface initialization.
• Updated documentation and manual

As always, if you find anything behaving in a way that is incorrect, or even directly rude or insulting, let me know.

One thing worth mentioning about this release is that discovered interfaces that have no version information in their announces will no longer be auto-connected, unless you allow this in the configuration. Version signalling was added in 1.5.2, and as far as I can tell, not a lot of backbone nodes are running versions earlier than that.

This is also the version that started introducing a lot of efficiency improvements, so in general, it's a lot better for the backbone network to only connect to 1.5.3+ nodes (where the final optimizations were added). But figured 1.5.2 would be a better cut-off for now, since there's still quite a few nodes around on that. Plz update :) Moar packets and stuff, you know.

When you first start up 1.5.5, you will probably see fewer auto-connects for an hour or two, until cached on-disk discovery announces are updated with version info. I did consider staggering this functionality over two releases, to avoid that initial couple-of-hours resync, but figured it was better to just get it over with.

Hey Mark! I know that QoS is a big part of development in the background; is version signalling intended to help service intelligent QoS based on awareness of what nodes are capable of?

Yes, that is part of it. Relatively soon, there will be some additional inter-backbone mechanisms to better handle traffic flow and QoS automatically (for example for voice packets), and to be able to seamlessly roll that out, the version signalling is very helpful.

Another important part is that other upcoming improvements, such as automatic per-connection IFAC ("v2" actually, will be faster than the current version), will need to have some indication of whether the remote interface supports the functionality, so a peer can pre-select the most suitable interfaces during auto-discovery (and automatically use the most suitable method). The same in this case, having an indication of the version will make it much smoother to introduce these upgrades without risks of incompatibility.

I get the following error. I had hoped it would go away after lxmd was started, but it didn't:

[2026-10-01 19:21:48] [Warning] Error while loading discovered interface data:
[2026-10-01 19:21:48] [Warning] The interface data file /home/pi/.reticulum/storage/discovery/interfaces/6fcce460cfda3c85fada9a4ee8b236c695c0c75439606816346d606fa5d18514 may be corrupt

[2026-10-01 19:21:48] [Error] An unhandled <class 'RNS.vendor.umsgpack.InsufficientDataException'> exception occurred:
[2026-10-01 19:21:48] [Error] Traceback (most recent call last):
File "/home/pi/.local/lib/python3.13/site-packages/RNS/Discovery.py", line 534, in list_discovered_interfaces
with open(filepath, "rb") as f: info = msgpack.unpackb(f.read())
~~~~~~~~~~~~~~~^^^^^^^^^^
File "/home/pi/.local/lib/python3.13/site-packages/RNS/vendor/umsgpack.py", line 957, in _unpackb3
return _unpack(io.BytesIO(s), options)
File "/home/pi/.local/lib/python3.13/site-packages/RNS/vendor/umsgpack.py", line 809, in _unpack
code = _read_except(fp, 1)
File "/home/pi/.local/lib/python3.13/site-packages/RNS/vendor/umsgpack.py", line 580, in _read_except
raise InsufficientDataException()
RNS.vendor.umsgpack.InsufficientDataException

Nice
I have to fix my kqueue branch before 1.6.0 :)

• Fixed timeout and response rejects not being processed for single-packet requests

Thank you. This was immensely frustrating trying to troubleshoot this with non-technical people who didn't understand why messages from Columba didn't go to propagation when it tried "opportunistic" delivery.