[FEAT] Connector Framework to evolve MeshMonitor into a multi-protocol mesh nexus

[jeremiahsb]

Why

I'm in an area that doesn't have a robust MeshCore community (yet) and the Meshtastic community is hit or miss. Thus I run multiple nodes (for the various protocols) and was going to work on expanding the support for MeshMonitor's support for MeshCore to run in a separate Docker container, but I had an idea. The app is great (especially the pass through capability), but it would fantastic if it was a nexus of the different protocols, all under a single UI. So, I thought I'd put this idea out there and see what folks thought of it.

MeshMonitor currently has strong Meshtastic support and partial MeshCore support, but they’re implemented as separate silos. That makes cross-protocol features hard and doesn’t scale well as more protocols are added.

Proposal (high-level)

Introduce a Connector Framework that wraps existing protocol managers and normalizes outputs (nodes/messages/channels/events) into a common model.

Core pieces:

• ConnectorAdapter interface per protocol (Meshtastic, MeshCore, future Reticulum/BitChat)
• ConnectorRegistry to manage lifecycle, routing, and unified queries/events
• connectors table plus connector_id on existing data tables (backward-compatible migration)
• Connector-aware API (/api/v2/connectors, unified nodes/messages endpoints)
• Connector management UI (add/edit/enable/disable/reorder, status, dynamic config schema)

Rollout plan

1. Phase 1 (Foundation)
   Connector interface/registry, DB migration, Meshtastic adapter, MeshCore adapter, connector CRUD/status API, basic UI

2. Phase 2 (Unified frontend)
   Unified map/messages/nodes/dashboard with connector filters, color/icon tagging, unread counts

3. Phase 3 (Reticulum)
   Python bridge + adapter + deployment support

4. Phase 4 (BitChat)
   Nostr-based adapter first, optional BLE direct later

5. Phase 5 (Relay engine)
   Rule-based inter-protocol forwarding with loop prevention/rate limits

Guardrails

• No big-bang rewrite of meshtasticManager as a prerequisite; start with thin adapters around existing code
• Preserve backward compatibility by auto-creating a default Meshtastic connector from existing env config
• Keep protocol-specific capabilities optional (graceful UI degradation where features don’t exist)

Feedback requested

1. Should connector-aware APIs be /api/v2 or incremental /api/v1 extension?
2. Is multi-instance Meshtastic a hard requirement in Phase 1, or can it be phased?
3. Preferred DB direction: unified tables with connector_id + protocol_data JSON vs protocol-specific tables?
4. Protocol priority after Phase 1: Reticulum first, BitChat later?

If this direction is acceptable, I’ll split implementation into incremental PRs by phase to keep review manageable.

[Yeraze]

Would this better implemented in MeshManager? I've been trying to keep MeshMonitor as a great Meshtastic-centric option, pulling data from it and others into MeshManager for multi-mesh features.

[jeremiahsb]

@Yeraze - it could, though it could be useful to have a common set of elements (i.e. UI, etc.) rather than having multiples to worry about. It's almost like merging MeshManager and MeshMonitor into a single app. A single UI, single API, single framework, etc. Then you could add adapters (i.e. reticulum, BitChat, etc.) and the core pieces are there. Plus a bit less administrative overhead to worry about (i.e. a single Docker container).

[MeshMATIC]

I like the idea of merging MeshMonitor and Meshmanager (I posted an idea like that on MeshManager github).
it seems a lot of functionalities could be shared between the two. Having everything into a single core app sounds good. With the possibility to instanciate the app in a specific mode.
meshtastic/meshcore/whatever monitor mode, or aggregator (MeshManager) mode.

[jeremiahsb]

Elements like the solar monitor could also be folded in. Maybe a concept like tools or connectors. Same with MQTT.

I can take a swing at this if you're keen. I'll pull a fork of it and work on getting phase 1 going. Would you rather use this repo or the other?

[Yeraze]

Keep it in a fork for now. I honestly doubt claude's ability to keep the multiple data flow paths and featuresets organized, thats one reason why I decided to separate things into different apps that communicate in a single standard API.

I've had so much trouble already just keeping meshtastic's features straight with firmware updates and internal data states. Adding in 3 more full ecosystems like a nearly impossible featureset to manage.