rns.recipes

Hello, I hope you're doing well. If I recall correctly, I previously heard about a setup involving an intermediary server to which the LoRa node connects, preventing it from receiving broadcast announce and thus saving bandwidth. This brings up a question: could an option be designed in Reticulum where the node receives no network announce? Instead, for tasks like messaging, the network would handle the lookup—sending a request to the server to locate the other party—rather than having a flood of announce sent to the node. Is this feasible? It seems to me that this would ensure traffic consumption on the client side remains virtually zero, both under normal conditions and if the network becomes congested. And well, is there a way to apply it across the entire network? For instance, even to auto-connections?

Some of this is managed at the interface configuration level which is a way to sanely configure LoRa nodes so they aren't transmitting announces non-stop...though without announces, clients need pre-knowledge of hashes (ensure you have Amber Pages bookmarked in your NomadNet browser). I can't speak to how that would work on the larger network, though.

I actually already have a Transport mode that does this implemented on a branch, but I need to get it rebased onto the newest changes and finish testing it. I have a workdoc about it here, which also explains the specific technical reasons why it's necessary in the first place: f9476617142a15bba88669b23ce58d58:/page/work_doc.mu`g=dev|r=reticulum|id=1|scope=active

The main application I have for this is sensor networks, and at least as I currently see it I don't think it's a good idea to use this mode on general-purpose LoRa networks. In essence it allows for flood routing at the first hop only, and without a lot of care you could end up degrading a network for everyone.

Looks like you deleted your reply while I was typing, but it’s relevant so I’ll still write this. Path requests for looking up a destination hash + interface modes to not propagate announces to low-bandwidth networks already handle these use cases in most applications. Transport nodes already act a distributed keystore of announces they’ve seen, which is queried by path requests. It’s only very specific cases where a client genuinely can’t afford to listen for or receive announces at all, or where they are rapidly roaming between transport nodes, where this new mode is relevant.

Wow! I didn't realize it involved so much work. I even used AI just to understand what you wrote.../// So, there are bound to be issues. Even if there were an option in Reticulum or the software to enable this, it would be best if it only activated under specific circumstances—like when conserving even that small amount of data is truly critical for you. Well, what you’ve built turned out to be even more ideal and efficient than I imagined—both in terms of data usage and power consumption, which is drastically reduced./// What if we didn't receive any announce at all, but instead—when connecting to a personal site or whatever—we entered the other party's hash? Could a structure be created (or maybe it already exists; I don't know) where we query servers to ask, "Who has received this hash?" As I write this, I realize the problem: since we aren't receiving announce, we’d have to search to see who holds it. Also, regarding finding the fastest route, we wouldn't be able to determine which connection is quicker because we haven't received the announce needed to know./// Still, is it better than the alternative scenario? I might just be spouting nonsense here—or perhaps only seeing half the picture—so I’m eager to hear your thoughts, given your deep understanding of how this network operates.

Yeah, I deleted it and rewrote it; it might look a bit silly—I’m not sure how to add line breaks here on the Nomadnet forum (: Thanks for the reply... So, this feature is actually available on the network now, right? But we have to enable it manually? I seem to recall a post here mentioning that changes were being made... Couldn't the process be a bit more automated? Like, just a checkbox to enable it fully? (:

Boltic wrote:

Yeah, I deleted it and rewrote it; it might look a bit silly—I’m not sure how to add line breaks here on the Nomadnet forum (: Thanks for the reply... So, this feature is actually available on the network now, right? But we have to enable it manually? I seem to recall a post here mentioning that changes were being made... Couldn't the process be a bit more automated? Like, just a checkbox to enable it fully? (:

I’m not sure which post you’re referring to. Path requests already exist, yes. All of the major clients (NomadNet, Columba, MeshChatX) handle them automatically for you if they don’t have a path to a destination.