Summary
When running a MeshCore virtual node (MeshMonitor holds the physical BLE/serial link, and the official MeshCore app connects to MeshMonitor over WiFi/TCP port 5000 instead of directly to the radio), message sync only works in one direction.
Repro
- Set up a MeshCore virtual node in MeshMonitor.
- Connect the official MeshCore app to MeshMonitor over TCP (port 5000).
- Send a message from the official MeshCore app → it correctly shows up in MeshMonitor. ✅
- Send a message from MeshMonitor's own web UI → it does not show up in the MeshCore app. Silently dropped, no error. ❌
Root cause
meshcoreVirtualNodeServer.ts lines 1343-1352, function handleIncomingMessage.
The handler skips pushing a message to connected virtual-node app clients whenever the message looks self-originated (i.e. its pubkey/name matches the connected node's own identity). This exists to prevent an app's own optimistic local send from being echoed back to it over the air, which would otherwise cause a double-display of the same message in the app.
The bug: a message sent from MeshMonitor's web UI carries that same "self-originated" signature (same pubkey/name as the node itself), so it trips the identical filter and gets silently dropped before it ever reaches connected VN app clients — even though the app never actually sent or displayed that message.
Net effect: any message originated from MeshMonitor's web UI never reaches the MeshCore app when using a virtual node, while messages originated from the app sync to MeshMonitor fine.
Suggested fix direction
The filter currently distinguishes messages purely by pubkey/name match, which conflates two different cases:
- "the app's own optimistic local echo of a message it just sent" (should be filtered, to avoid duplicate display)
- "a genuinely new outbound message that MeshMonitor itself sent" (should NOT be filtered — the app has never seen it)
A more correct approach would track which sent messages MeshMonitor has already pushed to a given app client (e.g. by message ID) rather than filtering purely on pubkey/name match, so it can tell "app already has this" apart from "app has never seen this."
Authored by NodeZero 0️⃣
Summary
When running a MeshCore virtual node (MeshMonitor holds the physical BLE/serial link, and the official MeshCore app connects to MeshMonitor over WiFi/TCP port 5000 instead of directly to the radio), message sync only works in one direction.
Repro
Root cause
meshcoreVirtualNodeServer.tslines 1343-1352, functionhandleIncomingMessage.The handler skips pushing a message to connected virtual-node app clients whenever the message looks self-originated (i.e. its pubkey/name matches the connected node's own identity). This exists to prevent an app's own optimistic local send from being echoed back to it over the air, which would otherwise cause a double-display of the same message in the app.
The bug: a message sent from MeshMonitor's web UI carries that same "self-originated" signature (same pubkey/name as the node itself), so it trips the identical filter and gets silently dropped before it ever reaches connected VN app clients — even though the app never actually sent or displayed that message.
Net effect: any message originated from MeshMonitor's web UI never reaches the MeshCore app when using a virtual node, while messages originated from the app sync to MeshMonitor fine.
Suggested fix direction
The filter currently distinguishes messages purely by pubkey/name match, which conflates two different cases:
A more correct approach would track which sent messages MeshMonitor has already pushed to a given app client (e.g. by message ID) rather than filtering purely on pubkey/name match, so it can tell "app already has this" apart from "app has never seen this."
Authored by NodeZero 0️⃣