rns.recipes

Over the last while, the network size and amount of connected transport nodes have grown considerably. The amount of weirdly configured and even half-broken instances have as well. One particular thing that has probably caused a lot of annoyance to many users is the fact that downstream topology can now change so rapidly in many cases, that more local nodes (including your own) do not receive announces for these downstream changes (because in some cases, there aren't any), and therefore link establishment fails, until a new announce for the desired destination arrives. In these situations, single-packet communication often still works. If you can recognize this, you've probably pulled your hair out a few times trying to get to a node, where link requests just keep timing out. Such a situation, of course, is a great opportunity to optimize things.

In the latest source version on Aleph, a new path upkeep mechanism has now been implemented: Link-request based path re-balancing. While we'd normally have to wait for an actual announce to arrive to update path table entries, there's a nice property about link-requests built into Reticulum; they contain just enough signed information to function as a sort of "micro-announce", and therefore update already existing path table entries.

This means, that if a link request is sent out, and the link destination is actually reachable on the network (so it can sign and respond with a link-request proof), all downstream transport instances on the return path can immediately re-balance their path table for the destination in question, at zero extra bandwidth, path requests or announce cost. There's a very slight extra processing load for this, but it only happens if the path actually needs re-balancing, and it's basically just one Ed25519 signature check and a table lookup.

This is all a bit complex, and I am of course over-simplifying things a bit here in the spirit of keeping things readable, but the practical result is, that on rapidly changing topologies with many hops, link request failures go from "I want to scream", to practically non-existent. I implemented this so that even the first link request over what would previously be an invalid path is dynamically re-balanced on the fly, on all intermediary nodes and finally at the link initiator itself, with the result that the link just connects. Which is quite nice.

Now, what I'd really love is if some of you good people who run large-ish transport nodes would help out in testing this. I'm already running this on two nodes with around 200-400 clients on each, and it really does seem to be working quite wonderfully, but as they say, there might be proof in your puddings and devils in the detail, et cetera, et cetera, so giving this a proper spin pre-release is probably a good idea.

On re-balancing events, you'll see something like this on transport nodes:

[2026-07-23 14:17:34] [Warning]  Re-balancing path to <9ce92808be498e9e05590ff27cbfdfe4> from link-request proof (6->4)

And on the link initiator:

[2026-07-23 14:17:33] [Debug]    Signalling link MTU of 262.14 KB for link
[2026-07-23 14:17:33] [Debug]    Establishing link with mode AES_256_CBC
[2026-07-23 14:17:33] [Debug]    Link request <fe2aad1092e35b15d8568eddea16e862> sent to <nomadnetwork.node.d96a927b963d22214e8c46dd879e5284:9ce92808be498e9e05590ff27cbfdfe4>
[2026-07-23 14:17:34] [Warning]  Unbalanced link path (4/6) detected on link <fe2aad1092e35b15d8568eddea16e862>, validating signature for re-balancing...
[2026-07-23 14:17:34] [Warning]  Re-balancing path to <9ce92808be498e9e05590ff27cbfdfe4> at link terminus (6->4)
[2026-07-23 14:17:34] [Warning]  Path table re-balanced for <9ce92808be498e9e05590ff27cbfdfe4>
[2026-07-23 14:17:34] [Debug]    Validating link request proof with mode AES_256_CBC
[2026-07-23 14:17:34] [Debug]    Destination confirmed link MTU of 8.19 KB
[2026-07-23 14:17:34] [Debug]    Link <fe2aad1092e35b15d8568eddea16e862> established with <nomadnetwork.node.d96a927b963d22214e8c46dd879e5284:9ce92808be498e9e05590ff27cbfdfe4>, RTT is 327ms and 3.72µs

Please report any weirdness or abominations encountered here in this thread (or directly to me over LXMF or email if it contains age-restricted details).

And also: Please see the other thread I just posted about interface gravity configuration, it ties in pretty well with this, and also really helps control stuff.

PS: If you, for reasons related to the above, cannot access the latest source code on Aleph, I posted a pre-compiled test wheel here:

https://github.com/markqvist/Sideband/releases/download/1.9.8/rns-1.4.0-py3-none-any.whl

Also, the [Warning] log-level is just to make it more visible in the logs while testing, it will drop to debug level once released.

Hell yeah, this is exciting! Neutral and I were talking about this a while back in RRC, I’m happy to see it implemented. I’ll try it out on rns.kin.earth probably tomorrow.

I’ve been waylaid by life and chronic illness, but the new test machinery is still coming along. We should be able to get some automated testing for this set up pretty soon (“soon TM”).

We're testing this on our network of ten transit nodes and can report that it is working very well. We also have interface gravity enabled along with autopeering and everything seems to be much more responsive. Thank you.

@10fde56e620ca825: If you don't mind, I would love to know more about the use of the nodes for transit. Are they feeding sensor data for enironment or are they for rgit?

I just appreciate the actual applications of the fabric at work.

Literally today I ran into this issue of single packets working but direct LXMF messages failing, but was taking turns driving on a big trip and didn't have any logs available to diagnose yet. Naturally you've already found a solution. Absolutely incredible, will update as soon as I can.

Thank you Mark!

Great to hear everyone, thanks for the feedback! Hah, that must have been a bit hard to debug in that situation Torlando :) This will all be out in version 1.4.1 relatively soon, along with some other fixes and optimizations. So far, my own testing also shows this is working as expected.

I've actually been wondering what other network information can be learned entirely passively. RTT can be gleaned from anything with a proof for example. It doesn't have to be part of the core protocol either but it could make pathing more intelligent

Aight everyone, 1.4.1 is out :)

With 1.4.1, my transport with 7 uplinks and hundreds of clients seems to find distant paths faster and hold on to them more reliably now. Thanks!

Maybe everyone just needs to update their nodes, but 1.4.2 seems to have broken something. Took 10+mins just to connect to this forum, or any nomadpage more than 2 hops away. Using MeshChatX (rns 1.4.1).

Everything works fine on my end, path requests and link establishement has never felt snappier. AFAICT, 1.4.2 didn't break anything on my transport node and client nodes.

Ok, half a day later, all seems ok now. Maybe just some early adoption weirdness.