LoRa Mesh

Findings

• The mesh carries the data, not the program. The obvious next question about a demo is how you would get it over the mesh in the first place, and the answer is arithmetic. The booking app's shell is 150 KB compressed — and 85 KB of that is the Meshtastic library and the polyfills it cannot build without, measured by building that library alone. Dropping the framework and half the app saves a fifth, not an order of magnitude. Over LoRa it is some 780 frames: hours on the default preset once the duty cycle is counted, which is the binding limit rather than the data rate. Against the 9.3 seconds a whole booking session costs, shipping the app is roughly fifty times everything it will ever do afterwards. So it arrives once — over Wi-Fi, a hotspot at the counter, or a code and a moment of internet — and is installed from then on. The lever that would change this is not a smaller framework but a smaller radio client: Meshtastic nodes also speak HTTP.
• 6 September 2026 — a booking crossed the mesh. Two Meshtastic nodes, EU 868, the slow default preset, and no IP path anywhere: a customer's booking travelled to the shop and stood in its own day plan 31 seconds later — an appointment the shop never entered. The whole session — rules, busy mask, booking — cost 9.3 seconds of airtime, about 2.5 % of what EU 868 grants a transmitter in an hour. That is the same radio on which a three-entry todo list is visibly sluggish. Nothing about the radio changed; the shape of the data did. The demo runs in a browser, with two tabs standing in for the radios if you have none.
• 4 September 2026 — first run over a real mesh, and the lesson came with it. Throughput: replicating even a todo list of three short entries is noticeably sluggish — and the radio is only half the explanation. The test setup used OrbitDB with network sync switched off: the courier carries the content-addressed blocks itself and puts them straight into the local blockstore — the IPFS network is never asked. (The blocks are hashed together and signed the way a blockchain's are: no entry can be altered without breaking every one that follows it. A chain it is not, though — an entry may have several parents, so concurrent writes branch and merge again, and there is no consensus. A blockchain's tamper-evidence, without its agreement.) First contact is the heavy part — manifest, access controller, identity and entries cross as a block bootstrap of a few kilobytes, roughly halved by gzip — and even afterwards, signatures and identity references keep every entry hundreds of bytes. On top sits the duty-cycle limit (EU 868: ~6 minutes of airtime per hour). The courier itself works — built and tested in funkpost, and that day it first ran over a real LoRa mesh between two independent nodes, a desktop browser either side — but standard office applications are ruled out. The setup can be tried live: the demo replicates a todo list across the mesh — or, with ?mesh=bc, across two browser tabs, no radio required.
• As a fallback for internet or power outages the current adaptation is unsuitable: it ships whole OrbitDB blocks, which the data rate does not carry. A follow-up release is already being considered that works the way mesh-calendar does — a few bytes of text per event instead of block transfers. What no release removes: every participant would still need radio hardware.
• Platform: Web Bluetooth runs only in Chromium on Android and desktop — no iOS browser. An iOS device is not locked out, though: over Wi-Fi — a mobile hotspot is enough — it can reach a node through Meshtastic’s HTTP/TCP API; a native app would also work and sits outside this evaluation. Device variance is real: a GrapheneOS phone talks to the node noticeably more stably than Android Chrome.
• Adoption: hardly anyone carries a radio node today. That is less a verdict than the actual design problem: commercial applications need ideas that do two things at once — spread the nodes and offer a benefit that justifies carrying one. A use case with a clear USP distributes its own hardware.

The three planes

Three planes share the one radio and nothing else, and each is named for what crosses it — a handshake, a database, an event. Two have run over real hardware and carry what that cost; the third is drawn and not built:

A courier for small, rare, valuable payloads. The signalling handshake from design issue #161 fits in two frames; a single signed event — a booking, a handover confirmation — in a few. Where minutes of latency are acceptable and infrastructure is absent, the model still holds — and metadata that is never generated cannot leak.

Technical foundations

• funkpost — the byte courier itself: framing, ARQ and duty-cycle pacing over Meshtastic® radios — two data planes built (OrbitDB and Yjs), signalling plane designed; live demos.
• webrtc-qr — the library: two devices connect by scanning a code — no signalling server.
• qr01 — the tutorial chapter for this: a todo list moves from phone to phone by scanning a code — over a Wi-Fi hotspot, with no internet involved.
• the demonstrators — both live in the browser: a todo list replicating across the mesh (OrbitDB), and an appointment book for a shop around the corner (Yjs). With ?mesh=bc two browser tabs stand in for the radios; a Meshtastic® node over Web Bluetooth makes it real.

Test channel

Two radios only hear each other if they carry the same key — and if they do not, nothing arrives and nothing says so, which looks exactly like an empty room. This is ours, published on purpose: a meeting place for anyone wanting to try the demonstrators with someone else. It is not a secret, and nothing in them was protected by the channel key in any case.

le-space.de · EU_868 · LONG_FAST · ⌗3dd3

Both demonstrators print that fingerprint beside the channel selector. It is worth comparing across devices: a channel can carry a familiar name and a completely different key, and the name will not tell you.

Importing replaces the entire channel set — every other channel on the device is erased, including keys that exist nowhere else. Export what is on there first.

• Role CLIENT_MUTE — a default node rebroadcasts everything it hears, and on a busy mesh that is most of its airtime, spent on strangers’ packets. Muted, it carries only its own.
• Preset SHORT_TURBO for heavy testing — 21,880 bit/s against LONG_FAST’s 1,070, so the same frame costs a twentieth of the air, and range is irrelevant across a desk. It is deliberately not baked into the channel above: the preset is part of the air configuration, so everyone testing together has to switch at once or they stop hearing each other.

The band is shared and legally rationed — EU 868 gives each transmitter about six minutes of airtime per hour, and a community mesh may have a hundred neighbours in earshot. Bench etiquette has the rest, and channels explains how to make your own.

Related work

• btcmesh — sends signed Bitcoin transactions over a Meshtastic mesh to a relay that broadcasts them — the same courier pattern, applied to money.
• darkwire — a Bitcoin 2025 hackathon project: an end-to-end Bitcoin transaction over LoRa, with no internet anywhere on the sender's side.
• Reticulum — the scene’s cryptography-first mesh stack — runs over LoRa, packet radio, Wi-Fi and everything in between; internationally the best-known work of this kind.
• MeshCore — a leaner LoRa mesh firmware currently building its own community in Germany alongside Meshtastic.
• qaul — a messenger for internet shutdowns — devices connect directly over Bluetooth and Wi-Fi; well known in the net-freedom scene.

Communities within reach

• Munich Mesh — the Munich Meshtastic community.
• Berlin Chaos Mesh — Berlin’s mesh community around the c-base — Meshtastic, MeshCore and Reticulum.
• MeshHessen — a regional mesh across the state of Hesse.
• Meshtastic local groups — the directory of all local groups, from the D-A-CH Telegram to lora.ms.