[Feature]: 2-byte and 3-byte node ID/hash support #15

New Issue

2026-10-05T01:52:38+02:00

adam commented

2026-10-05 01:52:38 +02:00

What feature do you want?
With firmware 1.14.0 now out, we now have the ability to advert with a 2-byte or 3-byte ID/hash instead of the historical 1-byte hash. I expect there may need to be some DB adjustments to support the higher byte counts when evaluating routing paths. We also should add the ability o set the advert ID/hash size in the 'radio & settings' tab. For companions this is done in the app settings and on repeaters it is done with a console command described in the post below.

Why do you need it?
With an increase in ID/hash size comes a large increase in total number of possible IDs in a region. This will ultimately solve for the limited ID count with a single byte hash that leads to many duplicate IDs in our networks.

1-byte (256 IDs)
2-byte (65,536 IDs)
3-byte (16,777,216 IDs)

Anything else?
Relevant post: https://buymeacoffee.com/ripplebiz/path-diagnostics-improvements

What feature do you want? With firmware 1.14.0 now out, we now have the ability to advert with a 2-byte or 3-byte ID/hash instead of the historical 1-byte hash. I expect there may need to be some DB adjustments to support the higher byte counts when evaluating routing paths. We also should add the ability o set the advert ID/hash size in the 'radio & settings' tab. For companions this is done in the app settings and on repeaters it is done with a console command described in the post below. Why do you need it? With an increase in ID/hash size comes a large increase in total number of possible IDs in a region. This will ultimately solve for the limited ID count with a single byte hash that leads to many duplicate IDs in our networks. 1-byte (256 IDs) 2-byte (65,536 IDs) 3-byte (16,777,216 IDs) Anything else? Relevant post: https://buymeacoffee.com/ripplebiz/path-diagnostics-improvements

adam closed this issue

2026-10-05 01:52:38 +02:00

adam commented

2026-10-05 01:52:39 +02:00

Indeed, I am actually working on a branch about this right this very second. There are actually a lot of touch points that need adjusting around radio configuration, new ingress shapes for packets, and variable radio firmware support. I am hoping to get something ready to go this week, but I've been dealing with a number of family emergencies, so things midi pushed out. I will keep this thread updated with my status.

Indeed, I am actually working on a branch about this right this very second. There are actually a lot of touch points that need adjusting around radio configuration, new ingress shapes for packets, and variable radio firmware support. I am hoping to get something ready to go this week, but I've been dealing with a number of family emergencies, so things midi pushed out. I will keep this thread updated with my status.

adam commented

2026-10-05 01:52:39 +02:00

Hey man no worries, it's gonna take us a matter of weeks to update all the repeaters to >=1.14.0 anyhow, just wanted to make sure the ball was rolling.

Laughing a little bit as I made a similar request on meshmapper and they were also already working on it without a posted feature request.

Cheers

Hey man no worries, it's gonna take us a matter of weeks to update all the repeaters to >=1.14.0 anyhow, just wanted to make sure the ball was rolling. Laughing a little bit as I made a similar request on meshmapper and they were also already working on it without a posted feature request. Cheers

adam commented

2026-10-05 01:52:40 +02:00

Haha Big moves everywhere. One of the hairier parts of this is that some of my front end parsing and some of the utilities that I bundle rely on the meshcore-decoder library which has not been updated yet, so I'm going to need to hand roll some packet parsing which I am deathly allergic to from a maintainability perspective. Backend stuff shouldn't be too big of a pain but correctness testing is going to be vital. Once I'm back near my radios on Monday, I'll spin up a multi-byte repeater and node so that I can feed myself some test traffic for validation.

Haha Big moves everywhere. One of the hairier parts of this is that some of my front end parsing and some of the utilities that I bundle rely on the meshcore-decoder library which has not been updated yet, so I'm going to need to hand roll some packet parsing which I am deathly allergic to from a maintainability perspective. Backend stuff shouldn't be too big of a pain but correctness testing is going to be vital. Once I'm back near my radios on Monday, I'll spin up a multi-byte repeater and node so that I can feed myself some test traffic for validation.

adam commented

2026-10-05 01:52:41 +02:00

Sounds good, let me know if there's something I can do to help support. My monitor and house repeater are already on 1.14.0

Sounds good, let me know if there's something I can do to help support. My monitor and house repeater are already on 1.14.0

adam commented

2026-10-05 01:52:41 +02:00

I appreciate it! Honestly I feel like I'm failing to get my head around something -- I have arrived at the conclusion that the intended scenario is "most to all of the mesh makes it to 1.14 and then you can turn on multibyte pathing" because otherwise there's no incentive to move to multibyte if all the legacy nodes and repeaters are just gonna drop your traffic. Maybe there's more nuance to that that I'm not grokking; is that your read?

I appreciate it! Honestly I feel like I'm failing to get my head around something -- I have arrived at the conclusion that the intended scenario is "most to all of the mesh makes it to 1.14 and then you can turn on multibyte pathing" because otherwise there's no incentive to move to multibyte if all the legacy nodes and repeaters are just gonna drop your traffic. Maybe there's more nuance to that that I'm not grokking; is that your read?

adam commented

2026-10-05 01:52:42 +02:00

Absolutely, need saturation of >=1.14.0 firmware in repeaters before we can really start using 2 or 3 byte paths. I suspect most regions will move to 2-byte to maintain a max of 32 hops but ultimately the user picks their setting. There is no firm enforcement method from repeater operators at this time although the loop control may have a bit of a clamp effect for people using 1-byte paths and expecting long range propogation as you're going to start having duplicates pretty quickly if only looking at 1-byte IDs.

I know our EUG region will likely move very quick for repeater support once we have a >1.14.0 firmware that's properly implementing power saving on the Heltec V4 (1.14.0 is broken for that). We think that may be next week via IOTthinks. Following repeater upgrades we'll follow with requiring 2-byte paths for mesh mapping and start recommending our users to use it on messages.

Absolutely, need saturation of >=1.14.0 firmware in repeaters before we can really start using 2 or 3 byte paths. I suspect most regions will move to 2-byte to maintain a max of 32 hops but ultimately the user picks their setting. There is no firm enforcement method from repeater operators at this time although the loop control may have a bit of a clamp effect for people using 1-byte paths and expecting long range propogation as you're going to start having duplicates pretty quickly if only looking at 1-byte IDs. I know our EUG region will likely move very quick for repeater support once we have a >1.14.0 firmware that's properly implementing power saving on the Heltec V4 (1.14.0 is broken for that). We think that may be next week via IOTthinks. Following repeater upgrades we'll follow with requiring 2-byte paths for mesh mapping and start recommending our users to use it on messages.

adam commented

2026-10-05 01:52:43 +02:00

Alrighty, we got a heartbeat. I need to work on my patience, too, but that's a problem for another day.

https://github.com/jkingsman/Remote-Terminal-for-MeshCore/pull/41 (branch multibyte-take-2) is ready for some road testing. I think I've buttoned up all the issues I can find. Decided just to fork the meshcore-decoder library and PR back; if they accept my PR I'll cut back to the original lib.

If you're up for it, I'd love for you take the branch out for a test drive please! It does mutate your DB with a migration, but will only ever write forwards migrations so when this merges you should be clear to cut over to main (do take a db backup beforehand, though; can never be too sure).

There are a lot of corner cases here -- the library not only accepts packet info from the radio interlink but also works a LOT with raw packets that we eat with our own parsing to enable historical decrypt etc. We're up to 400+ frontend tests and 1000+ backend tests, good god. I don't have a ton of confidence on the visualizer modifications to support repeater identity collapse on a reasonably reliable advert, but I've only got two repeaters I care to fiddle with for dev work and those seem to work reasonably, so eh.

At some point after this merge, I'll bang on the map display and get rid of those horrendous circles for something more concrete, and add packet-path heartbeat lines between nodes, which I'm super pumped for ahhh it's gonna look so cool.

I've submitted an issue but not a PR to meshcore_py for a bug in contact loadin that I found while cutting this over but I'm too tired tonight to make anymore code; I'm going to go to sleep and do nothing but play minecraft tomorrow and maybe PR next week if they don't patch it before I do.

I'm going to load this up onto my personal nodes, smoke check it for a couple days of usage, and then probably merge and cut a new docker image on Monday.

Alrighty, we got a heartbeat. I need to work on my patience, too, but that's a problem for another day. https://github.com/jkingsman/Remote-Terminal-for-MeshCore/pull/41 (branch `multibyte-take-2`) is ready for some road testing. I think I've buttoned up all the issues I can find. Decided just to fork the meshcore-decoder library and PR back; if they accept my PR I'll cut back to the original lib. If you're up for it, I'd love for you take the branch out for a test drive please! **It does mutate your DB with a migration**, but will only ever write forwards migrations so when this merges you should be clear to cut over to main (do take a db backup beforehand, though; can never be too sure). --- <rambling> There are a lot of corner cases here -- the library not only accepts packet info from the radio interlink but also works a LOT with raw packets that we eat with our own parsing to enable historical decrypt etc. We're up to 400+ frontend tests and 1000+ backend tests, good god. I don't have a ton of confidence on the visualizer modifications to support repeater identity collapse on a reasonably reliable advert, but I've only got two repeaters I care to fiddle with for dev work and those seem to work reasonably, so eh. At some point after this merge, I'll bang on the map display and get rid of those horrendous circles for something more concrete, and add packet-path heartbeat lines between nodes, which I'm super pumped for ahhh it's gonna look so cool. I've submitted an issue but not a PR to `meshcore_py` for a bug in contact loadin that I found while cutting this over but I'm too tired tonight to make anymore code; I'm going to go to sleep and do nothing but play minecraft tomorrow and maybe PR next week if they don't patch it before I do. I'm going to load this up onto my personal nodes, smoke check it for a couple days of usage, and then probably merge and cut a new docker image on Monday.

adam commented

2026-10-05 01:52:43 +02:00

Took a VM backup before pulling the new branch. I'm assuming it's multibyte-take-2. It seems like everything pulled over correctly, I didn't see any errors. Gonna try a few things now it's running.

ps: minecraft decompress is the best.

Took a VM backup before pulling the new branch. I'm assuming it's multibyte-take-2. It seems like everything pulled over correctly, I didn't see any errors. Gonna try a few things now it's running. ps: minecraft decompress is the best.

adam commented

2026-10-05 01:52:44 +02:00

Ok, stuff looks like it's working. It correctly set my ai7nc-mon to two-byte and it seems to show two byte paths correctly.

First thing I've noticed is when posting in the #eugene channel the messages showed correctly in remote term but did not show up in letsmesh.net despite remoteterm observer being connected and passing data to letsmesh.net

Edit: this of course could be a them problem not a remoteterm problem as that shared library doesn't have full 2-byte support yet.

Ok, stuff looks like it's working. It correctly set my ai7nc-mon to two-byte and it seems to show two byte paths correctly. <img width="440" height="844" alt="Image" src="https://github.com/user-attachments/assets/5ea50873-abfd-4615-8cd6-e7c4cf802d2a" /> First thing I've noticed is when posting in the #eugene channel the messages showed correctly in remote term but did not show up in letsmesh.net despite remoteterm observer being connected and passing data to letsmesh.net <img width="782" height="582" alt="Image" src="https://github.com/user-attachments/assets/2c0cfb1a-a4e0-491f-94c4-07e0bdb57962" /> <img width="830" height="494" alt="Image" src="https://github.com/user-attachments/assets/651d0425-fd25-487e-804d-dc507bd52120" /> Edit: this of course could be a them problem not a remoteterm problem as that shared library doesn't have full 2-byte support yet.

adam commented

2026-10-05 01:52:45 +02:00

Correct, LetsMesh is not multibyte ready. Glad to hear it seems like it's working; thank you so much for testing. I'm going to keep letting mine ride and probably merge tonight or tomorrow morning.

Correct, LetsMesh is not multibyte ready. Glad to hear it seems like it's working; thank you so much for testing. I'm going to keep letting mine ride and probably merge tonight or tomorrow morning.

adam commented

2026-10-05 01:52:46 +02:00

So why does sender and receiver show only 1 byte addresses? Both AI7NC-Mon and AI7NC-H2 are operating in 2-byte mode.

So why does sender and receiver show only 1 byte addresses? Both AI7NC-Mon and AI7NC-H2 are operating in 2-byte mode. <img width="440" height="844" alt="Image" src="https://github.com/user-attachments/assets/16902481-861c-4296-bd8b-fad3d6786839" />

adam commented

2026-10-05 01:52:46 +02:00

Eyyy great bug spotting; thanks. Commit is up to fix that.

Eyyy great bug spotting; thanks. Commit is up to fix that.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Remote-Terminal-for-MeshCore#15