rns.recipes

I've seen a few people mulling around this idea, where BLE is itself an interface. I don't especially love RNode. And I think that a "just works" bluetooth interface is feasible for building into RTNode

(Torlando if you're around and want to chime in)

This is what I'm imagining:

• BLE 4 GATT advertisement of service and data available (so no BLE 5 extended advertisement)
• BLE 4.3 Encrypted bonding negotiation with a 4-byte data available ID
• Short lived Encrypted GATT connections for data transfer

5 "data available" IDs could be advertised simultaneously

Now, the idea of this is not to have peer meshing of battery devices. I think that's untenable. The idea is to have the same functionality as RNode without having to pair one-to-one to a device. Both for convenience and for serving multiple devices

What do you guys have out there, or if not published, are already working on? Maybe we can converge on a protocol

jrl290 wrote:

I've seen a few people mulling around this idea, where BLE is itself an interface. I don't especially love RNode. And I think that a "just works" bluetooth interface is feasible for building into RTNode

(Torlando if you're around and want to chime in)

This is what I'm imagining:

• BLE 4 GATT advertisement of service and data available (so no BLE 5 extended advertisement)
• BLE 4.3 Encrypted bonding negotiation with a 4-byte data available ID
• Short lived Encrypted GATT connections for data transfer

5 "data available" IDs could be advertised simultaneously

Now, the idea of this is not to have peer meshing of battery devices. I think that's untenable. The idea is to have the same functionality as RNode without having to pair one-to-one to a device. Both for convenience and for serving multiple devices

What do you guys have out there, or if not published, are already working on? Maybe we can converge on a protocol

Super glad you're bringing this up. I feel the same way, and am right at the cusp of releasing my RNS port (about 1 week away now), which includes exactly this "BLE Auto-interface". You can see the sneak peek of it working cross-platform (desktop, mobile, and embedded) here: https://rns.recipes/forum/showcase/sneak-peek-your-personal-reticulum-hopspot

I'm also super with you on the stewardship of device battery, but I came to somewhat opposite conclusions on the approach. Scanning duty is the biggest lever to pull. Keeping an idle connection open is pretty cheap. I tried taking the angle you did at first too, but you end up (a) paying a lot of setup tax repeatedly, and (b) actually have a worse scanning obligation.

Any delay in picking up an advertisement is a data delay, so you have continual pressures on you to keep increasing the scan duty to properly handle that. And as soon as you start increasing that, you're hurting the battery the most. Now you might say (liek I did at first), "well the RNS network is meant to be latency-tolerant so that's fine", but it's trickier than that!

When you advertise that you have data, how far back does that go? Do we risk nodes constantly losing a bunch of data because the scan duty leaves gaps based on how long your peer retains data for? The obvious solution of "retain more data" is hostile to embedded sadly (who'd have to constrain themselves, again possibly bumping into the loss from your scan window).

On top of that, consider: links are time-sensitive, and large data can be moved over resources. Latency and history-storage costs surfacing again. ANd remember this would be at each and every hop including pure transport relaying, propagating that latency and storage pressure.

So my toiling led to the opposite conclusion, which is to intentionally look for those you can connect to eagerly and stay connected. Then, scan duty can stay lighter beacuse it's just delay to first contact, instead of the above thorny thicket of latency and storage concerns.

This is of course extremely early and open to refinement (the point of this thread), but the general approach I'm using is based on the learnings of tackling this problem so far, and is as follows:

Every platform implementation has a limit on total # of settled peers. While at least one of those slots is open:

• Every node scans and advertises (legacy-connectable) a protocol-known service UUID
• Every node eagerly dials to peers advertising
• In the initial handshake there's a BLE identity (specifically nothing to do with any RNS identity on the node), but that allows for correlating after reconnects and also:
• It's expected both sides will often dial each other. The BLE identity tells when there's a duplicate, and duplicates are resolved with a determinsitic keeper duel using info from the handshake.
• From there, it will continue to use the GATT as control plane, and will also use it for data plane as a fallback, but when possible an L2CAP CoC upgrade is attempted for the data plane and used when available instead of GATT.

Yes, you're right about all of this. Clearly from experience. I've tinkered with ble before and totally forgot that advertising was lighter on power than the scanning side. And you're also right about having to store data and wait for connection being untenable for ESP32

So maintaining links to other devices is the lowest power way to do it. And also has the benefit of letting the node pass packets straight through. It limits the number of simultaneous connections. But its still better than 1.

I'm sorry to say I did not watch through your video enough to get more than a gist. I'll have to sit down with it at some point. How much are we overlapping between your Hopspot (sorry again... I hate this name. Like viscerally) and my RTNode? I know you have much more UI crammed in there. RTNode has a clear scope: transport infrastructure. Blanket an area just like Meshtastic has done. Not meant to be touched once it's set up. I feel like yours is more meant to be a swiss army knife of connecting with your phone/computer/tablet? Not totally stand alone but not entirely set and forget either? Am I getting that right?

Mind you, I have no problem with competition even if we take different methodologies. All that matters to me is that the marketplace of ideas gives Reticulum its strongest foundation so that people who need this can depend on it where it is sorely needed. That said, I'll gladly adopt your BLE AutoInterface if it fits what I'm looking for. Including with Retichat

jrl290 wrote:

Yes, you're right about all of this. Clearly from experience. I've tinkered with ble before and totally forgot that advertising was lighter on power than the scanning side. And you're also right about having to store data and wait for connection being untenable for ESP32

So maintaining links to other devices is the lowest power way to do it. And also has the benefit of letting the node pass packets straight through. It limits the number of simultaneous connections. But its still better than 1.

I'm sorry to say I did not watch through your video enough to get more than a gist. I'll have to sit down with it at some point. How much are we overlapping between your Hopspot (sorry again... I hate this name. Like viscerally) and my RTNode? I know you have much more UI crammed in there. RTNode has a clear scope: transport infrastructure. Blanket an area just like Meshtastic has done. Not meant to be touched once it's set up. I feel like yours is more meant to be a swiss army knife of connecting with your phone/computer/tablet? Not totally stand alone but not entirely set and forget either? Am I getting that right?

Mind you, I have no problem with competition even if we take different methodologies. All that matters to me is that the marketplace of ideas gives Reticulum its strongest foundation so that people who need this can depend on it where it is sorely needed. That said, I'll gladly adopt your BLE AutoInterface if it fits what I'm looking for. Including with Retichat

Yeap limited simultaneous connections, but more than 1. Something so proximity limited like BLE works fairly well in that regard too (including the cases where two nodes move together, like keeping the device on you when hiking, etc.)

But yeah it's a full port of RNS that runs on all 3 platforms. That video is showcasing the use of said port (with emphasis on the embedded side especially at the beginning). So just like your original post here is positing: indepedently running instances that auto-connect with BLE. But, also auto connect over wifi (it's just he auto-interface), and use lora, and ESP-NOW in the espressif chip case, etc. Those are all just interfaces like any other, and since it's running Reticulum directly on board, it can use the interfaces the board provides.

I'm 100% in your boat with just wanting to make the ecosystme thrive. Exactly why threads like these are important (protocol stuff on automatic or default behavior, good to at least try and get a little consensus so we can all interop). For example the service UUID is the Columba/reticulum-ble one, and it has a compatibility interop layer, so it can wrap around what's already out there. This stuff matters a ton to me too!

Definitely keep the line open! Oh and IIRC your work is in Rust as well, right? The crate will be MIT/Apache so you can literally just use the interface directly from the crate while running your own RNS.

SUPER exciting times to be building!!

Every platform implementation has a limit on total # of settled peers. While at least one of those slots is open:

Every node scans and advertises (legacy-connectable) a protocol-known service UUID
Every node eagerly dials to peers advertising
In the initial handshake there's a BLE identity (specifically nothing to do with any RNS identity on the node), but that allows for correlating after reconnects and also:
It's expected both sides will often dial each other. The BLE identity tells when there's a duplicate, and duplicates are resolved with a determinsitic keeper duel using info from the handshake.
From there, it will continue to use the GATT as control plane, and will also use it for data plane as a fallback, but when possible an L2CAP CoC upgrade is attempted for the data plane and used when available instead of GATT.

This sounds very close to what I put together for ble-reticulum. Every node is both central and peripheral, with a shared known service UUOD, and has a limit of (7 for Android) connections. Handshake uses the Reticulum transport ID as a stable key to survive MAC rotation. Each side also spawns a fragmenter and reassembler in case negotiaties MTU is lower than 500 bytes (but typically between phones it's 512). Duplicates are resolved by sorting the MAC address to decide which side stays central.

My particular implementations have ended up being quite the battery hog so there's probably something I can dial in, just haven't had the attention on the protocol in quite some time.