NIP-BE: Nostr BLE Communications Protocol
NIP-BE sketches a Bluetooth Low Energy transport for Nostr-style messages, but it is marked unrecommended because it appears to have been implemented once and needs serious review before builders rely on it.
Offline and nearby sync is tempting, but hard
Nostr normally moves through relays over the internet. NIP-BE asks a different question: could nearby devices exchange Nostr messages over Bluetooth Low Energy when normal connectivity is limited or when a product needs local sync?
The NIP emulates a websocket-like client-server pattern over BLE. Devices advertise themselves, assign roles, expose write and read characteristics and move compressed NIP-01-style messages in chunks small enough for BLE.
That is an interesting idea for disaster scenarios, conferences, local devices or peer-to-peer sync. But the official warning is strong: unrecommended, implemented once, unclear whether it works and requires review.
BLE advertisement, GATT roles and chunked messages
A device advertises a service UUID and a device UUID. The GATT service uses a write characteristic and a read/notify characteristic. Devices compare UUIDs to decide which becomes the GATT server and which becomes the client, with special all-ones and all-zero UUIDs for fixed-role devices.
Messages follow NIP-01 message structure, then are compressed with DEFLATE. If too large, they are split into chunks with a batch index and last-batch marker. Only one message is read or written at a time. Maximum message size is 64KB.
This is transport plumbing, not a new event format. The hard part is making BLE reliable enough for Nostr assumptions.
A single implementation path became an unrecommended NIP
KoalaSat added NIP-BE in November 2025 through PR #1979. On May 31, 2026, fiatjaf added the unrecommended warning across NIP bodies, and the warning for BE explicitly says only implemented once and unclear whether it works.
That warning should guide the page. This NIP belongs in the atlas because it is in the official set, but it should not be sold as production-ready local mesh infrastructure.
A builder interested in BLE should treat the current file as a design sketch and testbed, not a settled compatibility layer.
Prototype with strict limits and visible failure states
An implementation should negotiate MTU carefully, reject oversized messages, reassemble chunks defensively and make failures visible. BLE can drop, reorder or delay in ways ordinary websocket clients may not expect.
Security assumptions also need care. Nearby-device discovery can reveal presence. A local transport does not remove the need to verify Nostr signatures, event kinds and relay-style policy.
The safest product stance is experimental support with clear labels.
Transport novelty can hide reliability problems
A Nostr message that works over websocket may fail over BLE because of chunking, MTU limits, device sleep, platform permission prompts or background restrictions.
The unrecommended status is not decorative. It is the central implementation signal.
Direct sources
Use the official file first, then the commit history, implementation references and adjacent standards. NIPs move, and product guidance gets weaker when those source trails are hidden.
