No second LoRa radio required — companions, room servers, and a safety-scoped IP bridge, working today

[smellyspice]

I've been building on a fork that adds non-LoRa meshing options — ESP-NOW attachments and an IP bridge between repeaters — and wanted to share where it's landed, since a few long-running threads (notably Issue #37) describe almost exactly these use cases.

Reference site with the full breakdown of each piece: https://smellyspice.github.io/MeshCore/

ESP-NOW: companions, room servers, and repeaters with no LoRa radio at all

A board with no LoRa hardware — just an ESP32 with WiFi — can join an existing repeater's mesh over ESP-NOW, appearing as a normal companion, room server, or repeater. Local, short-range, no internet path involved at all. This directly covers the "roof repeater / indoor node without a second LoRa radio" and "silent room server, no direct LoRa access" cases raised in Issue #37.

Two things fell out of the same work:

• A room server can passively mirror one group channel's messages into its own post feed, turning a channel's chatter into a readable history automatically — nobody has to relay messages into it by hand.
• A repeater running both ESP-NOW and its IP bridge automatically shares real NTP time with anything attached to it, so a board with no other time source (no LoRa adverts to pull a timestamp from, no battery-backed clock) doesn't drift to a bogus default.

IP bridge: the part that's drawn a firm no before

This is scoped narrowly on purpose: one repeater, one configured peer, not a public broker anyone can join.

I know the objection already raised in Issue #37: that IP bridging encourages routing mesh traffic over the internet, and that unwanted traffic from that can clog meshes fast. That's a real risk for an open, many-to-many topology — a handful of independently-built bridges chaining unrelated cities together can amplify a flood nobody asked for. It doesn't automatically follow from a single point-to-point link between two repeaters whose operators already coordinated to set it up, any more than a long RF hop between two repeaters is inherently unsafe just because RF hops can also be misused.

Three things specifically keep this scoped:

• One airtime budget, no exceptions. Local, ESP-NOW-bridged, and IP-bridged traffic all funnel through the same duty-cycle-based transmit budget on the real radio.
• Region scoping applies identically. MeshCore's existing region/transport-code scoping sits in the same receive pipeline regardless of whether a packet arrived over LoRa or a bridge. An operator can turn either bridge into a hard broadcast boundary with existing CLI config alone.
• A real RF path always gets first shot. The IP bridge deliberately holds back new-path traffic briefly whenever a real RF neighbor is present, giving a genuine multi-hop LoRa path a chance to win the race before falling back to IP — so IP fills in where RF genuinely isn't there, instead of quietly out-competing it. Full mechanics, including the one edge case where this can't detect a real alternate path, are on the reference site.

It also doesn't require touching the public internet at all — the same bridge works over a private LAN, a VPN, or a point-to-point radio link, joining two sites into one mesh with nothing facing outward. And it's useful for bootstrapping too: seed a repeater in an area with no LoRa neighbors yet by linking it to an established repeater over IP, and once local repeaters go up and start hearing each other over real RF, the IP link steps back into a backup role instead of staying load-bearing.

What this is

The branch has some rough edges from iterating fast on real hardware — it doesn't need to be merge-ready to be worth sharing now. Mostly wanted to surface that the ESP-NOW side of this is working and usable today, and that the IP bridge was built with the flooding/scope concern in mind from the start, not as an afterthought. Happy to go deeper on any of the mechanics here or in the reference site's own detail.