under evaluation
LoRa Mesh
We set out with an idea: web apps that keep their data on the devices themselves (local-first) and keep running over a LoRa® radio mesh when the internet or the power grid fails, and in places that have neither. The measurements did not bury that idea; they cut it to size. The radio cannot carry the volumes of data people move every day. It does carry handshakes, bookings and signed events reliably across kilometres, with no infrastructure anyone has to operate. What the evaluation produced is a class of applications: mesh-calendar, an experimental appointment manager for hairdressers, already runs inside that byte budget.
Findings
29 September 2026 the change travels, not the entry. For one ticked box it is now the change itself that goes on the air, not the whole database entry that carried it.
- 86 bytesagainst 1774
- 10 secondsagainst three and a half minutes
The log is the running list in which every change stays, signed, and an entry in it carries a signature, an identity and references to its predecessors. That is why it weighed 1774 bytes, measured over the real courier. The change itself is 86: the key and the value that OrbitDB already hands to every listener. On a carrier that moves half a kilobyte a minute, that is ten seconds against three and a half minutes.
The same morning a heartbeat crossed two real nodes and came back in well under a minute, answered on the first beat of its round. Two sequence diagrams show the route and why it does not produce a duplicate.
The limits are drawn beside it rather than after it. The two logs diverge. One edit is lost when both devices change the same entry while offline. And a device cannot yet notice that an earlier change never arrived; that part is being built now. This remains an evaluation rather than a product, and we ask that it be read as one: the demonstrators are where it is built, deployed and tried.
21 September 2026 a list that outlives the phone. A phone that had been reset got its list back with nothing in hand but the security key.
A Galaxy Fold 5 made a list and backed it up to an IPFS server; the phone was then reset. A Galaxy A57 loaded the list straight back from IPFS, with nothing but the YubiKey the identity derives from. Nothing else was needed.
Not settled: keeping the backup. Aleph takes the file without an account but does not promise to keep it; that takes a storage order signed by a wallet. The recovery page shows every step and whom it contacts.
19 September 2026 an identity that outlives the phone. Two phones that had never exchanged anything carry the same identity, derived from a security key rather than stored anywhere.
One security key and two phones that had never exchanged anything, a Galaxy Fold 5 and a Galaxy A57: the same address and the same signing key on both. A passkey does not hand out its public key, but two of its signatures admit exactly one, so the address is recovered rather than remembered.
What that buys is a list that survives a lost device: backed up wherever there is internet, found again by a name computed from the key, and writable on the replacement, because the database’s write rule, its access controller, recognises the same writer. The identity half was measured on hardware that day, the database half followed on 21 September. The procedure is written up in full.
18–19 September 2026 internet first, and the mesh when it goes. When the connection goes, only what changed since has to cross the radio.
- 145 bytesone frame for the pointer
- 7 frameswhat first contact costs otherwise
An earlier finding here called the OrbitDB adaptation unsuitable as a fallback, because it ships whole blocks the data rate does not carry. The blocks are as heavy as they were; the fallback no longer has to ship them. Two phones that have been syncing over the internet already share the log.
And a list’s first contact can leave the radio altogether: the few kilobytes that cost about seven frames. A frame is a single radio packet, and not much more than two hundred bytes fits in one. Whoever next has internet backs the list up and sends a pointer of 145 bytes, one frame. The other side fetches the rest from an IPFS gateway over HTTPS, with no account.
The app establishes the loss by asking the network rather than believing a flag. Before moving onto a carrier with a rationed budget, it asks. And it can ask the channel whether another app is listening, 33 bytes out and 32 back, rather than counting radios in range. Shown end to end in browser tests over a simulated mesh; the run across two real nodes is still outstanding, and the run sheet says in advance what it has to show. What no release removes: every participant still needs radio hardware.
6 September 2026 a booking crossed the mesh. A customer’s booking stood in the shop’s own day plan, with no IP path anywhere.
- 31 secondsuntil the booking stood
- 9.3 secondsof airtime, 2.5 % of the hour
Two Meshtastic nodes, EU 868, the slow default preset and no IP path anywhere. An appointment the shop never entered. The preset is the radio setting that trades range against speed.
The whole session of rules, busy mask and 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.
6 September 2026 the mesh carries the data, not the program. Shipping the app itself over the radio would take hours, so it arrives once by another route and is installed from then on.
- 150 KBthe app, compressed
- 780 framesthat over LoRa
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, 85 KB of that 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 that is some 780 frames, and so hours on the default preset once the duty cycle is counted. That is the binding limit, not 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. The lever that would change this is not a smaller framework but a smaller radio client: Meshtastic nodes also speak HTTP.
4 September 2026 first run over a real mesh. A todo list replicates between two browsers over a real mesh, and even three entries are noticeably sluggish.
- ~6 minutesof airtime an hour, EU 868
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 and signed the way a blockchain’s are, only without its consensus: entries may have several predecessors, branches merge back. Tamper evidence without agreement. First contact is the heavy part, because 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, the airtime the law allots: in EU 868 about six minutes an hour.
The courier itself works, built and tested in funkpost and that day run for the first time over a real LoRa mesh between two independent nodes, a desktop browser either side. Standard office applications are ruled out by it. The setup can be tried live: the demo replicates a todo list across the mesh.
Platform. Web Bluetooth runs only in Chromium on Android and desktop, in no iOS browser.
An iOS device is not locked out, though: over Wi-Fi, and 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, and 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, the short exchange two devices use to agree a connection, a database, an event. Two have run over real hardware and carry what that cost; the third is drawn and not built:
The scheduling example exists now: mesh-calendar, a hairdresser’s appointment book running in the browser, where two tabs stand in for the radio when none is connected. Positioned not as a fallback for internet outages but as an alternative path: appointments synchronised into existing scheduling tools while generating no metadata in the first place.
The cut of the data decides what radios at all. The salon never sends a schedule: it sends the rules plus a busy mask: one bit per slot, three weeks in about 112 bytes, one frame, however full the calendar is. Free slots are computed locally, so browsing costs no airtime.
Yjs carries the rules; the log carries the bookings. The rules are written by a handful of stable devices, where merging genuinely helps. The bookings sit beside them in a log of signed, immutable records. Because a Yjs document greets its peers with a summary that grows with every author who has ever written: about six kilobytes, thirty frames, after a thousand customers, and it never shrinks. The log’s greeting is one small fingerprint per day, the same size at any scale, and it forgets last month instead of remembering it for ever.
What stays off the air is just as deliberate. The cancellation token (it lives in the .ics link; only the derived public key enters the document), the .ics file itself, and the verdict on a contested slot, which every device computes identically on read. Convergence is not agreement, so agreement is calculated, not transmitted.
Authority is a signature, not a convention. A decision not signed by the salon’s key is discarded on read, and a cancellation must carry the booking’s own capability signature. And the sync goes quiet on agreement: peers whose days match exchange one frame and fall silent.
Try a plane
Both run in the browser. With ?mesh=bc two tabs stand in for the two radios, so neither needs hardware to try. A Meshtastic® node over Web Bluetooth makes it real. The run sheet says what a session on real radios still has to show. They are demonstrators, not products; the menu page says what that means.
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.
Test channel
Two radios only hear each other if they carry the same key. 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_FAST for heavy testing: 10,940 bit/s against LONG_FAST’s 1,070. The same frame costs a tenth of the air, and range is irrelevant across a desk. Not SHORT_TURBO: it needs 500 kHz of bandwidth, EU 868 is 250 kHz wide, and it has no usable slot there at all. The preset is deliberately not baked into the channel above: it 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. Etiquette at the bench 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.
Exchange
We share measurements and the test setup. Anyone working in the same niche is welcome to get in touch: Meshtastic practitioners, researchers, local-first developers.
Get in touch — contact@le-space.de Telegram · @lfp2p X · @nicokrausex
On the mesh, we can be reached at le-space.de e45c, YSGs0MrcH9QOcAlIxvYkJWaV64AvKgx/tXS27SiCzXM=
The public key is what identifies us; node names are assigned by whoever operates the node. It radios in the EU-868 region and is mobile, so it is reachable wherever it currently has a mesh in range.
LoRa® is a trademark of Semtech Corporation. Meshtastic® is a registered trademark of Meshtastic LLC. Meshtastic software components are released under various licenses, see GitHub for details. No warranty is provided - use at your own risk. This site is not affiliated with or endorsed by Semtech or the Meshtastic project.