twisla/roro9stack
Public Access
1
0
Fork 0
Code Issues 48 Pull Requests Actions Packages Releases 16 Activity

M4: design round for the Mesh Service, the Messenger and the Node List #23

New Issue
Open
opened 2026-10-05 20:07:15 +00:00 by twisla · 1 comment
twisla commented 2026-10-05 20:07:15 +00:00
Owner
Copy Link
Copy Source

What

The question round that opens M4, as for every milestone, ending in docs/milestones/M4.md. This issue collects what's already decided and what's parked, so the round starts from one place.

Already decided

  • Scope (first design round): Mesh Service receive-only, Messenger, Node List. Sending is M5.
  • ADR 0001: our own Meshtastic implementation with nanopb and Meshtastic's published protobufs. Partial compatibility at first: text on Channels, Direct Messages, node list, position, Relaying. PKI-encrypted Direct Messages and the phone-app API are deferred.
  • Defaults: Region EU868, LongFast, Client role, hop limit 3.
  • The Radio Service (M3) owns the radio; the Mesh Service sits on top of it, keeps it listening at all times (M3, Q100), and is paused, visibly, by a Sweep (Q99).
  • Clock: time learned from the mesh is the least trusted source (Mesh < NTP < GNSS).
  • Glossary: Mesh Service, Mesh Protocol, Node, Channel, Direct Message, Relaying (CONTEXT.md).

Parked for this round

  1. Position (M2, Q65): the position never leaves the device before M5, but M4 decides at what precision it will be shared, and what we do with the positions we receive.
  2. A radar of other Nodes by distance and bearing (M2, Q60): in the Node List, the GNSS App, or the Compass (#16)?
  3. Which packet types are decoded and shown: text, node info, position, telemetry, routing? What happens to the rest?
  4. Where the node database lives (NVS or the card), how many Nodes it keeps, and when one is forgotten.
  5. Message history: a Log on the card per Channel and per Node, its format, its Storage Clean-up category.
  6. Channels: only the default one at first, or adding Channels with their own keys? How is a key entered (typed, a file on the card, a Meshtastic channel URL)?
  7. Direct Messages received: recent Meshtastic firmware encrypts them with the recipient's public key. Receive-only, can we read any at all before our own key pair exists?
  8. Notifications and unread counts: which traffic raises a Toast, which only counts.
  9. Power: the radio never sleeps from M4. What does that cost on the 1750 mAh battery, and does the screen-off state change anything?
  10. Memory: the Mesh Service next to Wi-Fi, IRC on TLS and Gemini, against the floors (G1, Q86).
  11. A second Mesh Protocol later (MeshCore): what must stay generic now?

Related

docs/adr/0001-own-firmware-speaking-meshtastic.md, docs/milestones/M2.md (Q60, Q65), docs/milestones/M3.md (Q92, Q99, Q100, Q104), CONTEXT.md, #16, #20.

## What The question round that opens M4, as for every milestone, ending in `docs/milestones/M4.md`. This issue collects what's already decided and what's parked, so the round starts from one place. ## Already decided - **Scope** (first design round): Mesh Service receive-only, Messenger, Node List. Sending is M5. - **ADR 0001:** our own Meshtastic implementation with nanopb and Meshtastic's published protobufs. Partial compatibility at first: text on Channels, Direct Messages, node list, position, Relaying. PKI-encrypted Direct Messages and the phone-app API are deferred. - **Defaults:** Region EU868, LongFast, Client role, hop limit 3. - **The Radio Service** (M3) owns the radio; the Mesh Service sits on top of it, keeps it listening at all times (M3, Q100), and is paused, visibly, by a Sweep (Q99). - **Clock:** time learned from the mesh is the least trusted source (Mesh < NTP < GNSS). - **Glossary:** Mesh Service, Mesh Protocol, Node, Channel, Direct Message, Relaying (CONTEXT.md). ## Parked for this round 1. **Position** (M2, Q65): the position never leaves the device before M5, but M4 decides at what precision it will be shared, and what we do with the positions we receive. 2. **A radar of other Nodes** by distance and bearing (M2, Q60): in the Node List, the GNSS App, or the Compass (#16)? 3. Which packet types are decoded and shown: text, node info, position, telemetry, routing? What happens to the rest? 4. Where the node database lives (NVS or the card), how many Nodes it keeps, and when one is forgotten. 5. Message history: a Log on the card per Channel and per Node, its format, its Storage Clean-up category. 6. Channels: only the default one at first, or adding Channels with their own keys? How is a key entered (typed, a file on the card, a Meshtastic channel URL)? 7. Direct Messages received: recent Meshtastic firmware encrypts them with the recipient's public key. Receive-only, can we read any at all before our own key pair exists? 8. Notifications and unread counts: which traffic raises a Toast, which only counts. 9. Power: the radio never sleeps from M4. What does that cost on the 1750 mAh battery, and does the screen-off state change anything? 10. Memory: the Mesh Service next to Wi-Fi, IRC on TLS and Gemini, against the floors (G1, Q86). 11. A second Mesh Protocol later (MeshCore): what must stay generic now? ## Related `docs/adr/0001-own-firmware-speaking-meshtastic.md`, `docs/milestones/M2.md` (Q60, Q65), `docs/milestones/M3.md` (Q92, Q99, Q100, Q104), CONTEXT.md, #16, #20.
twisla added this to the M4 Mesh receive milestone 2026-10-05 20:07:15 +00:00
twisla added the
kind
docs
area/lora
status
needs-design
priority
medium
 labels 2026-10-05 20:07:15 +00:00
twisla commented 2026-10-06 01:45:21 +00:00
Author
Owner
Copy Link
Copy Source

A question for this round, from #20: the GNSS receiver raises the LoRa radio's noise floor by 8 dB while it runs (-98 against -106 dBm at 125 kHz, measured three times). From M4 the Mesh Service keeps the radio listening all the time, so the two can't both be on at their best.

Options to decide between:

  1. GNSS stays on, and the mesh hears 8 dB worse: roughly half the range in open terrain.
  2. GNSS runs in bursts: a Fix now and then for the position and the clock, standby in between. How often, and what does a Track do?
  3. GNSS only while something needs it: the GNSS App open, a Track recording, the clock unset.

A setting exists already (Settings > Pause GNSS for LoRa, off by default) that pauses the receiver while the radio listens; with an always-on radio that's option 3 without the exceptions. It also saves the receiver's 33 mA.

**A question for this round, from #20:** the GNSS receiver raises the LoRa radio's noise floor by 8 dB while it runs (-98 against -106 dBm at 125 kHz, measured three times). From M4 the Mesh Service keeps the radio listening all the time, so the two can't both be on at their best. Options to decide between: 1. GNSS stays on, and the mesh hears 8 dB worse: roughly half the range in open terrain. 2. GNSS runs in bursts: a Fix now and then for the position and the clock, standby in between. How often, and what does a Track do? 3. GNSS only while something needs it: the GNSS App open, a Track recording, the clock unset. A setting exists already (Settings > Pause GNSS for LoRa, off by default) that pauses the receiver while the radio listens; with an always-on radio that's option 3 without the exceptions. It also saves the receiver's 33 mA.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/apps
Launcher and the apps in src/apps
 area/audio
Microphone, speaker, the codec, recording and playback
 area/build
PlatformIO, Docker, scripts, partitions, sdkconfig
 area/cluster
AtomS3 co-processors on Grove and the link protocol
 area/gemini
GeminiService, the Gemini App, Saved Pages
 area/gitea
The Gitea client: issues, releases, its TLS and its token
 area/gnss
GnssService, the GNSS App, Tracks
 area/ir
The infrared LED and the IR Remote
 area/irc
IrcService and the IRC App
 area/lora
The Cap LoRa-1262 radio and the mesh
 area/ota-debug
Updates, Probation, Safe Mode, Debug Console, crash reports
 area/power
Battery, PowerService, sleep
 area/scripting
Lua Apps from the SD card and their API
 area/ssh
The SSH client and its terminal
 area/storage
StorageService, the SD card, Storage page
 area/ui
Canvas, widgets, dialogs, Toasts, fonts, keyboard
 area/vpn
The WireGuard tunnel
 area/website
The project website and its docs
 area/wifi
WifiService, Wi-Fi Settings, Wi-Fi Tools
 concern/memory
May push the heap towards its floors; measure on the device
 concern/security
TLS, signing, the debug token, trust on first use
kind
bug
Something that doesn't work as it should
kind
chore
Refactors, tooling, CI, scripts
kind
docs
README, CONTEXT, milestones, ADRs
kind
feature
Something new the device can do
priority
high
Next up
priority
low
Some day
priority
medium
Soon
status
blocked
Waiting on something else
status
needs-design
Needs a question round (Qnn) before code
status
ready
Designed; can be started
No labels area/lora
kind
docs
priority
medium
status
needs-design
Milestone
No items
No Milestone M4 Mesh receive
Assignees
Clear assignees
twisla (Clément Martin)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: twisla/roro9stack#23