rns.recipes

Just curious to see if perhaps we could see something like "routing groups" in the future to better define transport node behavior?

For instance, a personal transport node may have an rnode, several backbones, and autointerface configured. The intent for transport here is that the rnode can be shared amongst ethernet-linked devices, and those devices can also reach out to the public mesh without configuring the backbones on all of the local devices. Though, in this case, we would expect to transport between the backbones, right? In the case that they are being accessed over a metered (and junk-fee filled) internet connection, it would be undesirable to provide transport to the public mesh in this instance.

Solution: routing groups. For each interface, they can receive a list of routing groups they participate in. Each backbone is given their own group name (bb1, bb2, bb3), and the rnode gets its own as well (lora). The autointerface, though, gets all of the groups defined earlier (bb1, bb2, bb3, lora). Now, traffic coming in to a group can only get routed to the interfaces that are a part of that same group. Backbone1 traffic doesn't get transported to backbone2, but the local devices can still interact with nodes reachable by any backbone or the rnode, preventing the chances of catching that big fee for using too much data. Of course we would still need to add a switch for allowing/blocking transport within the same interface (node 1 on backbone1 trying to reach node 2 that is also on backbone1).

Thoughts? Is this a terrible idea, or something that might be desirable?

Definitely not a bad idea, this kind of functionality would be very useful. It is something I've also been thinking about, but haven't really had the time yet to sit down and design it correctly. While it seems relatively simply in theory, there's a lot of details to consider ;)

But also, you can achieve a very high degree of this functionality already using the different interface modes, gravity and associated options. It's just not as intuitive as setting a named group and being done with it.

The general design of the different mode options and extra modifiers you can apply per interface has been to create something that can cover a lot of different scenarios by combining them in different ways. It's quite powerful, but also requires a bit of headscratching at first.

Anonymous wrote:

Of course we would still need to add a switch for allowing/blocking transport within the same interface (node 1 on backbone1 trying to reach node 2 that is also on backbone1).

Desperately yearning for more control over path traversal manipulation?

"Use that 'one easy trick' to help Mallories increase sybil influence of Alice's discovery peers", said Olivia, as she reached to pull her segmenting 'eclipse switch' to keep Mallory persistently on-path in an ever growing network.