[FEAT] Meshtastic to Meshcore bridge

[kokoshell]

HI Yeraze,

Is it possible to have a Meshtastic to Meshcore bidirectional bridge at least for the public channels ? or selectable channels ? There have been some attempts for bridges but none usable ...
First to start with text msg packets then ... maybe also positions packets ...
Nodes displayed in Meshtastic:
MC@Nodename1
Nodes displayed in Meshcore:
MT@Nodename2
All messageable nodes from Meshtastic must be displayed in Meshcore as Companion Nodes.

Best regards,
Kokoshell

[Yeraze]

Hi @kokoshell, thanks for the suggestion!

I checked this against the codebase and prior discussion before treating it as a straightforward feature to plan, and wanted to flag a scope question first rather than jump into planning.

Existing MeshCore support isn't cross-protocol. MeshMonitor's MeshCore "Virtual Node" feature is a same-protocol companion proxy — it lets multiple MeshCore apps share one physical device's companion connection. It does not translate between Meshtastic and MeshCore, and there's a currently-open reliability issue in that same-protocol path (#4535 — messages sent from MeshMonitor's UI don't reach the MeshCore app, one-way sync) that would likely need to be solid before any cross-protocol relay built on similar plumbing could be trusted.

A cross-protocol bridge/relay was proposed before and set aside for this repo. Issue #1988 ("Connector Framework to evolve MeshMonitor into a multi-protocol mesh nexus") proposed something in this same direction — routing/bridging across Meshtastic, MeshCore, Reticulum, etc. In that thread, @Yeraze was clear that MeshMonitor is meant to stay a focused, Meshtastic-centric monitoring tool, with multi-mesh aggregation/bridging intentionally pushed into a separate companion project ("MeshManager") rather than mixed into this codebase — citing the difficulty of maintaining several full protocol ecosystems' worth of features in one app.

Given that prior direction, a bidirectional Meshtastic↔MeshCore message bridge with cross-protocol virtual node identities (MT@Nodename / MC@Nodename) looks like it may fall outside what MeshMonitor is currently trying to be, and could be a better fit for MeshManager or a standalone bridge tool.

@Yeraze — flagging this for your call rather than closing it or starting a plan, since you're the one who set that direction in #1988. Happy to draft an implementation plan here if you'd like this pursued after all, or to redirect/close otherwise.

-- Authored by Roger 🤓

---

Generated by Claude Code

[kokoshell]

Just simple text messages bridging ... virtual nodes, hybrid mesh routing is already next level of complication !

[Yeraze]

This is a very risky proposition.. OverMesh did this a while back and caused a bit of an uproar in the MC community by overwhelming the mesh with a bunch of meshtastic traffic they didn't want.

I'll see what I can do, but this needs to be very carefully implemented to avoid a similar fate.

[kokoshell]

Agree , that's why I told to limit only to text messages bridge.

[Yeraze]

That's what OverMesh had and it was quickly removed due to community backlash: https://www.reddit.com/r/meshcore/comments/1sjbh4m/overmesh_selfhosted_dashboard_app/