Noshtastic: How to Run a Nostr Relay Over Meshtastic LoRa Mesh

Why put Nostr over LoRa at all?

Nostr (Notes and Other Stuff Transmitted by Relays) is a minimalist, cryptographically signed social protocol. Every event — a note, a DM, a reaction — is a self-contained JSON object signed by the author’s private key. Relays are simple servers that store and forward events. Because events carry their own signatures, you can pass them through any transport that can carry bytes: WebSockets over the internet, Tor hidden services, Bluetooth — or LoRa radio.

Meshtastic turns inexpensive LoRa radio modules into a self-organizing mesh network. Each node relays messages from its neighbours, extending coverage without infrastructure. In a dense enough deployment, messages hop across cities. In a sparse rural deployment, a pair of nodes can communicate tens of kilometres line-of-sight.

Put them together and you get a Nostr relay that works when the internet is down, blocked, or censored. That property is worth a great deal to anyone building sovereign communication infrastructure. It is also why this space is attracting serious open-source contributors despite the technical difficulty.

The two main projects: noshtastic and nostrastic

As of mid-2026 there are two distinct open-source efforts tackling Nostr-over-LoRa in different ways. They share a goal but use different architectures. Neither project is affiliated with D-Central — we document them here because they represent genuine contributions to sovereign communication infrastructure that builders should know about.

Noshtastic (ksedgwic)

Noshtastic (github.com/ksedgwic/noshtastic), written by Ken Sedgwick, describes itself as “a broadcast negentropy meshtastic nostr relay.” It is written in Rust and takes a full relay approach: each noshtastic node runs a complete local Nostr relay and synchronises its event database with peer nodes via the LoRa link.

The architecture has four components that work together:

• noshtastic-relay — a localhost Nostr relay process. Your Nostr clients (mobile apps, desktop clients) connect to this relay over WebSocket on localhost, exactly as they would connect to any internet relay.
• noshtastic-sync — a modified implementation of the negentropy set-reconciliation protocol. Rather than naively broadcasting all events, two nodes first determine which events the peer is missing, then send only those. This is critical at 1 kbps: wasted bytes cost seconds.
• noshtastic-link — the LoRa transport adapter. It encodes events, fragments them into LoRa-sized packets, and reassembles fragments received from the radio.
• nostrdb — a local event database used by the relay to persist events.

Events intended for noshtastic distribution carry a geohash location tag, allowing the relay to scope synchronisation to a geographic region (for example, all nodes in a city’s quadrant). This prevents every node from trying to sync the entire global Nostr event graph — which would be impractical at radio bandwidth.

Nostrastic (QuixoteSystems)

Nostrastic (github.com/QuixoteSystems/nostrastic) takes a lighter approach: it is a bridge application that publishes Nostr posts and sends/receives direct messages (DMs) over LoRa using a connected Meshtastic device. Rather than running a full local relay, it acts as a gateway — translating between Nostr events and Meshtastic messages at the application level. The project describes itself as a beta/proof-of-concept.

The two projects represent different philosophies. Noshtastic is infrastructure — a relay that any Nostr client can connect to. Nostrastic is a bridge — a specific application for posting and DMs. Both are experimental.

How noshtastic synchronisation works

The core technical challenge in Nostr-over-LoRa is bandwidth efficiency. A standard Nostr event — even a short text note — is typically 300–600 bytes of JSON after serialisation. At LoRa’s LongFast preset (~1 kbps effective data rate with the default 250 kHz bandwidth and spreading factor 11), transmitting a single event takes approximately 3–5 seconds of airtime, before fragmentation overhead. The Meshtastic managed-flood algorithm adds further delay as messages hop between nodes.

Noshtastic’s solution is the negentropy protocol. Negentropy is a set-reconciliation scheme: two peers exchange compact summaries of their event sets, compute the difference, and then transfer only the missing items. In a network where most nodes already share most events, this means a typical sync round transfers very little data — just the delta. The protocol is well-suited to low-bandwidth links precisely because it minimises unnecessary transmissions.

The process for a new event arriving at a local Nostr relay:

1. The event is stored in the local nostrdb database.
2. noshtastic-sync detects the new event and determines which peer nodes lack it via the negentropy summary exchange.
3. noshtastic-link fragments the event into LoRa-packet-sized chunks (Meshtastic’s maximum payload per packet is 233 bytes — Constants.DATA_PAYLOAD_LEN in current Meshtastic protobufs; older releases allowed 237 — and payloads are typically smaller).
4. Fragments are broadcast over the Meshtastic radio channel and reassembled by receiving nodes.
5. Receiving nodes store the event in their local relay, which serves it to locally connected Nostr clients.

The honest bandwidth reality

Understanding what noshtastic can and cannot do requires understanding LoRa’s fundamental constraints. This is not a limitation of noshtastic’s design — it is physics.

Parameter	Typical LoRa / Meshtastic LongFast	Impact on Nostr relay
Effective data rate	~1 kbps (SF11, 250 kHz BW, CR 4/5)	A 500-byte event takes ~4 seconds of airtime
Maximum packet payload	Up to 233 bytes (current Meshtastic limit; formerly 237)	Most Nostr events require 2–5 fragments
Duty cycle (EU ISM band)	1% (legal limit in most of Europe)	Maximum ~36 seconds of transmission per hour
Channel capacity (shared medium)	Shared among all nodes in range	Dense networks saturate quickly; Meshtastic recommends no more than ~30–50 active nodes per channel
Practical throughput	Dozens of short messages per hour under normal mesh load	Low-volume text notes only; no images, no video, no large payloads

What works well: Short text notes (NIP-01 kind 1 events), direct messages (NIP-04/NIP-44), profile metadata (NIP-01 kind 0), reactions (NIP-25). All of these are small, self-contained JSON events that fragment into a handful of LoRa packets.

What does not work: Long-form articles, images encoded in data URIs, video, large file attachments, high-frequency feeds. These require internet-connected relays.

The right mental model: Noshtastic is not a replacement for internet-connected Nostr relays — it is a resilience layer. Think of it the way you think of a Bitcoin transaction broadcast over LoRa mesh: useful when normal channels are unavailable, not intended for everyday volume use.

Use cases where this is genuinely useful

Disaster and emergency communication

When internet infrastructure is down following a natural disaster, a grid outage, or coordinated infrastructure attack, a Meshtastic mesh with noshtastic nodes can continue exchanging short Nostr notes between participants in a geographic area. Because Nostr events carry their own cryptographic signatures, there is no central authentication server that needs to be online.

Events and gatherings without coverage

Remote conferences, camping events, hiking expeditions, and off-grid communities can deploy a small noshtastic mesh to maintain a shared Nostr social feed within the group. Participants use standard Nostr clients pointed at localhost — the radio layer is invisible to the application.

Censorship-resistant last-resort communication

In jurisdictions where internet access is blocked or heavily monitored, a local LoRa mesh sidesteps the censored channels entirely. LoRa operates on ISM (license-free) spectrum bands; the signal carries no identifying metadata at the radio level. This is part of the broader digital sovereignty use case.

Bridging isolated communities

Rural communities with intermittent or expensive internet connectivity can use noshtastic to maintain a local Nostr feed that synchronises to internet relays whenever connectivity is available, and continues operating locally when it is not.

Hardware you need

Running noshtastic requires two layers of hardware: Meshtastic-compatible LoRa nodes and a host system to run the relay software.

LoRa nodes

Any Meshtastic-supported device can serve as the radio layer. Common choices include LILYGO T-Beam (ESP32 + SX1276 LoRa + GPS), Heltec LoRa 32 (compact, popular for fixed nodes), and RAK WisBlock modules (modular, suited to custom enclosures). As of 2026, most Meshtastic hardware uses the SX1262 or SX1276 radio chipset. Prices vary; see the device comparison for current options and range characteristics via the range calculator.

Host system for the relay

Noshtastic runs on any system that can run Rust binaries and connect to a Meshtastic node via USB serial or Bluetooth. A Raspberry Pi (any model with USB) is the typical self-hosting choice for a always-on node. A laptop works fine for experimentation.

Nostrastic, being a lighter bridge application, has lower requirements and can run on single-board computers or even Android devices paired with a Meshtastic radio.

Current development status (mid-2026)

Both projects are experimental and under active development. This is important to flag clearly:

• Noshtastic (ksedgwic/noshtastic) is written in Rust, has a defined architecture, and has been demonstrated working in testing. It is not production-ready software. The GitHub repository is the primary reference — check the README for current build instructions and known limitations before attempting deployment.
• Nostrastic (QuixoteSystems/nostrastic) is explicitly described as a beta proof-of-concept. Expect rough edges.
• Neither project has shipped a stable release or documented production deployment at the time of this writing. Treat them as research-grade tools.
• The broader Nostr-over-LoRa problem space is being tracked in the Nostr protocol repository (github.com/nostr-protocol/nips/issues/246 — “Low bandwidth implementations”), indicating protocol-level interest in formalising compact event formats for constrained links.

If you are evaluating these projects for deployment, check the repositories directly for the current commit activity and open issues. The field is moving quickly.

How this fits the sovereign communication stack

Noshtastic occupies a specific niche in a layered sovereignty architecture. Think of the stack this way:

Layer	Tool	What it gives you
Radio mesh (physical)	Meshtastic on LoRa hardware	Off-grid, infrastructure-free node-to-node connectivity
Social protocol	Nostr (NIP-01 events)	Cryptographically signed, server-agnostic social graph
Sync efficiency	Negentropy (noshtastic-sync)	Bandwidth-optimal event set reconciliation between nodes
Client interface	Any standard Nostr client (Damus, Amethyst, Snort, etc.)	Users see a normal Nostr experience; radio layer is transparent
Bitcoin layer (optional)	BTC Mesh alongside noshtastic	Transaction broadcast + zap capabilities without internet

The full sovereign stack — local LLM inference, Nostr communication, Bitcoin transactions, mesh networking — is documented in the sovereign stack guide.

Standing on the shoulders of giants

Noshtastic and the broader Nostr-over-LoRa movement build on years of open-source work by many contributors. It would be dishonest to present this work without naming who did it:

• The Meshtastic project (meshtastic.org) — the firmware, protocol, and app ecosystem that makes affordable LoRa mesh accessible. Hundreds of contributors, GPLv3 licensed.
• fiatjaf and Nostr contributors — the Nostr protocol is intentionally minimal and deliberately open; the NIP process enables exactly this kind of transport experimentation.
• yewbow and the negentropy project (github.com/hoytech/negentropy) — the set-reconciliation algorithm that makes bandwidth-efficient sync possible. Noshtastic’s noshtastic-sync is a modified fork.
• Ken Sedgwick (ksedgwic) — author of noshtastic; the technical architecture described on this page is his work.
• QuixoteSystems — nostrastic bridge project, a parallel and complementary approach.

D-Central documents and contextualises this ecosystem. We did not build these protocols. Our role is to help builders understand which tools exist, what they actually do, and where their limits are — so you can deploy sovereign infrastructure with accurate expectations.

Frequently asked questions

What is noshtastic?

Noshtastic is an open-source Rust project by Ken Sedgwick that runs a Nostr relay over a Meshtastic LoRa mesh network. It uses the negentropy set-reconciliation protocol to synchronise Nostr events between nodes efficiently, minimising the amount of data transmitted over the low-bandwidth radio link.

What is the difference between noshtastic and nostrastic?

Noshtastic (ksedgwic) is a full local Nostr relay with LoRa transport — any Nostr client can connect to it via WebSocket. Nostrastic (QuixoteSystems) is a lighter bridge application for publishing posts and DMs specifically. Both are experimental as of mid-2026.

Can I use Nostr over Meshtastic without the internet?

Yes, that is the core use case. Noshtastic nodes exchange events over LoRa radio with no internet dependency. You can communicate within your local mesh entirely off-grid. When internet connectivity is available, nodes can bridge events to and from standard internet-connected Nostr relays.

How fast is Nostr over Meshtastic?

Slow, honestly. Meshtastic’s default LongFast preset provides approximately 1 kbps effective throughput. A short Nostr text note (400–600 bytes of JSON) takes several seconds of airtime to transmit, plus fragmentation and multi-hop relay delay. Expect minutes-scale latency for a note to propagate across a multi-hop mesh. This is a tool for resilience, not convenience.

What hardware do I need to run noshtastic?

You need at least one Meshtastic-compatible LoRa radio (any supported device — LILYGO T-Beam, Heltec LoRa 32, RAK WisBlock, etc.) connected via USB or Bluetooth to a host computer running the noshtastic software. A Raspberry Pi is the typical self-hosting setup. For a minimal mesh you need at least two such nodes at separate locations.

Is noshtastic production-ready?

No. As of mid-2026, noshtastic is experimental software under active development. It has been demonstrated working in testing environments, but it has not reached a stable release. Check the GitHub repository (github.com/ksedgwic/noshtastic) for current status before attempting deployment in any critical-use scenario.

Can I send images or video over Nostr-over-Meshtastic?

No. LoRa bandwidth is ~1 kbps — images and video are completely impractical. Even a small JPEG of 50 kB would take approximately 7 minutes of dedicated airtime on a single channel. Text-only events are the realistic scope of what noshtastic can relay today.

What is negentropy and why does noshtastic use it?

Negentropy is a set-reconciliation algorithm: two peers exchange compact summaries (fingerprints) of their event databases to determine what the other is missing, then transfer only the missing items. On a 1 kbps radio link, naively broadcasting all events would saturate the channel. Negentropy ensures that each transmission carries new information, making it far more bandwidth-efficient than a simple broadcast relay.

What Nostr clients work with noshtastic?

Any standard Nostr client that supports adding custom relay WebSocket URLs. Noshtastic exposes a localhost WebSocket endpoint; you add it as a relay in your client (Damus, Amethyst, Snort, Coracle, etc.) the same way you would add any internet relay. The radio transport is invisible at the client layer.

How does noshtastic relate to the broader sovereign stack?

Noshtastic provides the social/communication layer in an off-grid sovereign stack. It pairs naturally with Bitcoin-over-Meshtastic (for value transfer), a local Nostr relay on a home server (for internet-bridged sync when available), and Meshtastic mesh infrastructure (physical radio layer). See the sovereign stack guide for the full architecture.