I run a mixed mesh at home: Meshtastic radios plus a Reticulum network (RNode LoRa and LAN transport). I wanted both on one potato-mesh dashboard, so I built Reticulum support and have it running in production on my instance. Before opening PRs I want a maintainer read on a few conventions, since one of them touches the federation spec.
What it does
A new PROTOCOL=reticulum provider in data/mesh_ingestor, modeled on the meshcore provider. It is a passive announce listener using the rns package: it registers announce handlers for the lxmf.delivery and nomadnetwork.node aspects, maps each announce to a node record (display name from app_data, receipt time, hop count), and posts through the existing queue and API. The dependency is import-guarded the same way meshcore's is, so meshtastic-only deployments don't install it.
On the web side: reticulum joins the protocol whitelist and gets its own stats scope, an instances.reticulum_nodes_count column, an icon, and a filter chip. Reticulum nodes carry no SNR, battery, or position, so those columns render as dashes and the nodes stay off the map.
Decisions I'd like your read on
Node id mapping. CONTRACTS.md leaves the Reticulum id space undefined. I used ! plus the first 4 bytes of the 16-byte destination hash, with the full hash preserved in user.publicKey. This mirrors the meshcore first-4-bytes-of-pubkey rule. Fine to standardize, or do you want a different scheme?
Federation. SPEC S6 froze the protocol whitelist, and my change amends it: the self announcement now signs a live reticulum_nodes_count. The v2 canonical form already carried the field as a signed zero, so signatures from older peers still verify, and older peers relay the count as 0. Acceptable, or should this wait for a spec revision?
One physical peer can appear as two node rows, one per destination aspect. The payload doesn't carry the aspect today. I can add a field if you'd rather distinguish or merge them.
Scope. Announces only in this cut. Message, position, and telemetry ingest would need an LXMF delivery identity on the ingestor and an opt-in story, so I left them out.
Testing
Python suite went from 1215 to 1264 tests, Ruby from 1684 to 1699, JS from 1706 to 1711, all passing, black clean. My production instance has been running it with 30 meshtastic nodes and 3 reticulum nodes side by side.
Happy to split the work into an ingestor PR and a web PR referencing this issue.
I run a mixed mesh at home: Meshtastic radios plus a Reticulum network (RNode LoRa and LAN transport). I wanted both on one potato-mesh dashboard, so I built Reticulum support and have it running in production on my instance. Before opening PRs I want a maintainer read on a few conventions, since one of them touches the federation spec.
## What it does
A new `PROTOCOL=reticulum` provider in `data/mesh_ingestor`, modeled on the meshcore provider. It is a passive announce listener using the `rns` package: it registers announce handlers for the `lxmf.delivery` and `nomadnetwork.node` aspects, maps each announce to a node record (display name from app_data, receipt time, hop count), and posts through the existing queue and API. The dependency is import-guarded the same way meshcore's is, so meshtastic-only deployments don't install it.
On the web side: `reticulum` joins the protocol whitelist and gets its own stats scope, an `instances.reticulum_nodes_count` column, an icon, and a filter chip. Reticulum nodes carry no SNR, battery, or position, so those columns render as dashes and the nodes stay off the map.
## Decisions I'd like your read on
1. Node id mapping. CONTRACTS.md leaves the Reticulum id space undefined. I used `!` plus the first 4 bytes of the 16-byte destination hash, with the full hash preserved in `user.publicKey`. This mirrors the meshcore first-4-bytes-of-pubkey rule. Fine to standardize, or do you want a different scheme?
2. Federation. SPEC S6 froze the protocol whitelist, and my change amends it: the self announcement now signs a live `reticulum_nodes_count`. The v2 canonical form already carried the field as a signed zero, so signatures from older peers still verify, and older peers relay the count as 0. Acceptable, or should this wait for a spec revision?
3. One physical peer can appear as two node rows, one per destination aspect. The payload doesn't carry the aspect today. I can add a field if you'd rather distinguish or merge them.
4. Scope. Announces only in this cut. Message, position, and telemetry ingest would need an LXMF delivery identity on the ingestor and an opt-in story, so I left them out.
## Testing
Python suite went from 1215 to 1264 tests, Ruby from 1684 to 1699, JS from 1706 to 1711, all passing, `black` clean. My production instance has been running it with 30 meshtastic nodes and 3 reticulum nodes side by side.
Happy to split the work into an ingestor PR and a web PR referencing this issue.
<!-- github-sync-id:5189586991 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I run a mixed mesh at home: Meshtastic radios plus a Reticulum network (RNode LoRa and LAN transport). I wanted both on one potato-mesh dashboard, so I built Reticulum support and have it running in production on my instance. Before opening PRs I want a maintainer read on a few conventions, since one of them touches the federation spec.
What it does
A new
PROTOCOL=reticulumprovider indata/mesh_ingestor, modeled on the meshcore provider. It is a passive announce listener using thernspackage: it registers announce handlers for thelxmf.deliveryandnomadnetwork.nodeaspects, maps each announce to a node record (display name from app_data, receipt time, hop count), and posts through the existing queue and API. The dependency is import-guarded the same way meshcore's is, so meshtastic-only deployments don't install it.On the web side:
reticulumjoins the protocol whitelist and gets its own stats scope, aninstances.reticulum_nodes_countcolumn, an icon, and a filter chip. Reticulum nodes carry no SNR, battery, or position, so those columns render as dashes and the nodes stay off the map.Decisions I'd like your read on
!plus the first 4 bytes of the 16-byte destination hash, with the full hash preserved inuser.publicKey. This mirrors the meshcore first-4-bytes-of-pubkey rule. Fine to standardize, or do you want a different scheme?reticulum_nodes_count. The v2 canonical form already carried the field as a signed zero, so signatures from older peers still verify, and older peers relay the count as 0. Acceptable, or should this wait for a spec revision?Testing
Python suite went from 1215 to 1264 tests, Ruby from 1684 to 1699, JS from 1706 to 1711, all passing,
blackclean. My production instance has been running it with 30 meshtastic nodes and 3 reticulum nodes side by side.Happy to split the work into an ingestor PR and a web PR referencing this issue.
Reposted from my main account as #888, closing this duplicate.