John Richards, a resident and Meshcore user, told the Bonner County audience that Meshcore is a recent fork of Meshtastic designed to reduce channel congestion and add store‑and‑forward room servers. He explained the primary technical differences, demonstrated device examples and fielded questions about interoperability, device compatibility and use in field operations.

Why it matters: Meshcore’s room‑server model stores messages on a local server node and delivers them to clients when they log in, which can make messaging more reliable for users who turn devices off or whose batteries die during field operations. That store‑and‑forward behavior could be valuable for community or incident communications that expect intermittent connectivity.

John described the routing contrast this way: Meshtastic uses a flood‑routing approach that can fill bandwidth when many devices broadcast simultaneously; Meshcore instead uses a path‑ or nomination‑based approach in which nodes reduce unnecessary rebroadcasting. He said this makes Meshcore “more efficient” in congested deployments and that room servers act like small bulletin‑board systems that retain messages until clients request them.

Room servers (also called VBS or room servers in the presentation) require a node configured to accept and store messages; clients then authenticate and retrieve missed messages when they reconnect. John demonstrated work‑in‑progress all‑in‑one devices that include display, GPS and battery, and said the Meshcore firmware family includes client, repeater and server variants depending on role. He noted device vendors used for both Meshtastic and Meshcore include LILYGO and Rack, and that many boards are interchangeable because Meshcore’s firmware is a fork of earlier Meshtastic code.

On interoperability and limitations: John said Meshcore and Meshtastic do not interoperate by default but development is active and workarounds (for example, dual‑booting devices to run either firmware) exist. He also said some Meshcore features (for example, certain map imagery on specific devices) may require a small fee (one example discussed was an $8 unlock for map features on a particular device) and that server‑to‑server federation features were still nascent.

Quotes and community notes: John said, “Meshtastic does flood routing…it's like everybody's screaming in a room at each other,” using the remark to illustrate why some users have adopted path routing. He emphasized he remains a Meshtastic supporter: “I love Meshtastic...please don't...I'm not discouraging you from using Meshtastic.”

Ending: Audience Q&A covered whether room servers communicate with each other (uncertain), compatibility with ATAC and ATK mapping clients (work underway), and which devices the presenter recommended for base stations versus handheld use. John encouraged attendees to test both platforms and noted the ecosystem is evolving quickly.