rns.recipes

The latest source version of RNS of Aleph introduces interface gravity configuration. From the manual:

The gravity option specifies the pathing affinity of an interface. If not set specifically, and unless otherwise configured by default_gravity or autoconnect_interface_gravity, it defaults to 0. Positive values increase pathing affinity, and negative values decrease it.

This means, that each individual interface can now have a gravity value configured, and if multiple interfaces receive the same announce, the interface with the highest gravity wins the path table entry. This is especially useful for operators running transport nodes with public entrypoints, where many users continously connects and disconnects.

For example, since some programs have established a recent trend of just enabling transport by default on everything, this leads to situations where John Doe's phone is now part of your path, as he's strolling down the streets of Maryville. Phone is not doing much, and has a good fast connection right now, so as such, that's actually perfectly within the intended behavior of Reticulum - it delivers the announce most efficiently to the next transport node. Problem only is, in five minutes John enters the subway, and that path is gone.

(Okay okay okay, I know, the whole default transport thing was already fixed, but I'm just poking a bit of fun to illustrate the situation, and from what I can see, a lot of people are actually still running things like that, maybe intentionally, maybe not, who knows?)

Either way, with gravity this is much easier to just configure once, and then forget about. For example:

[reticulum]
  default_gravity = 25                # Default high gravity for our static, known-good peers
  autoconnect_interface_gravity = 15  # Prefer static, but higher priority to auto-connects too

[interfaces]

  # Our internal downlinks gets the
  # highest gravity, so paths nodes
  # there are always reached directly.
  [[Core Downlinks]]
    enabled = yes
    type = BackboneInterface
    mode = internal
    gravity = 50
    device = enp2s0
    port = 41862
    block_fast_flapping = no
    passphrase = udWaydHusBebyotEdLidveb3

  # Two known-good high-performance
  # backbone links, these inherit the
  # default high gravity.
  [[Backbone Peer 1]]
    enabled = yes
    type = BackboneInterface
    mode = gateway
    remote = some.host.tld
    target_port = 4242

  [[Backbone Peer 2]]
    enabled = yes
    type = BackboneInterface
    mode = gateway
    remote = other.place.tld
    target_port = 4242

  # Our public entrypoint is open to
  # the chaos of the world, so this
  # gets a lower gravity than the rest.
  [[Public IPv4]]
    type = BackboneInterface
    mode = gateway
    gravity = 10
    enabled = yes
    device = enp1s0
    port = 4242

It's worth noting that the gravity mechanisms are currently (and intentionally) rather rudimentary. Once the core concepts have been tested, and probably adjusted a bit, it will serve as the basis for much more intelligent behavior, and is a required part of the picture before multi-pathing and path redundancy.

Please also see the other post I just made about dynamic path re-balancing. Any help testing all of this out on transport nodes across the network is much appreciated!

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

Connecting to nomadnet sites seems to a little more snappy on my backbone server which I'm guessing gravity is responsible for out of the two changes in this version because I won't default to going through some random connection on my public interface.

Question, would it make sense to give a lower gravity to lower bitrate and higher latency interfaces such as I2P or LoRa if you are serving a public interface for either? Would that decision still make sense if you were not a transport node?

Interface gravity can definitely be used on non-transport nodes and normal devices as well to better control the pathing affinity according to whatever you like. For low-bandwidth/high-latency interfaces, it's probably not going to change the pathing decision much in practice though, since path will almost certainly end up going over faster/lower-latency interfaces if destinations are reachable there anyway. But if you have specific needs in that regard, no harm in experimenting with what works best.

Sounds very useful, but I dont fully understand the example. Where would the transport node phone be connected in the config given, and how would interface gravity help here exactly?