NIP-BE: Nostr BLE Communications Protocol
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 guides the page. This NIP belongs in the atlas because it is in the official set, but it must not be sold as production-ready local mesh infrastructure.
A builder interested in BLE needs to 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 needs to 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.
Read NIP-BE in the wild
NIP-BE explores BLE communication for local Nostr exchange. It is useful at conferences, offline-adjacent moments and nearby device flows where the internet path is awkward.
Proximity is not safety. Pairing, spoofing, replay and device permissions need careful handling before a local transport becomes a trusted channel.
What changes when you actually use it
For you, NIP-BE: Nostr BLE Communications Protocol is felt when a specialized experience still remains portable. Games, forums, handlers, static sites and local transports become useful only when another client can understand the same object. The source terms unrecommended, draft, read-message, EVENT, EOSE are the difference between an open feature and a private app convention.
What changes for builders and operators
For builders, NIP-BE: Nostr BLE Communications Protocol needs cross-client proof. Create an object in one product, open it in another, then test what survives without special server knowledge. That is where an app-specific idea becomes a real Nostr surface.
What the official file makes concrete
The official file is organized around Device advertisement, GATT service, Role assignment, Messages, Examples, Workflows, Client to relay, Relay to client. Inspect unrecommended, draft, read-message, EVENT, EOSE because these are the pieces most likely to surface as product behavior. Read it beside NIP-01, NIP-77 before treating it as isolated.
NIP-BE: Nostr BLE Communications Protocol earns trust when a second client can understand the same object without a private handshake.
Where it breaks
The failure mode in NIP-BE: Nostr BLE Communications Protocol is private interoperability. The event exists on Nostr, but only the original app knows how to use it. Test a second interface and a second relay before calling the feature portable.
Where this appears outside the markdown
In the ecosystem, NIP-BE: Nostr BLE Communications Protocol is where Nostr stops being only a feed and becomes a surface for specialized products: forums, games, static sites, handlers, local transport or application state. The standard matters only when another client can open the same object without calling the first app for private instructions.
The nearby-standard trap
The nearby-standard trap in NIP-BE: Nostr BLE Communications Protocol is mistaking novelty for interoperability. A clever app-specific event is not a standard until another client can use it. Read NIP-01, NIP-77 to see whether the feature has a path out of its first product.
Language that keeps the feature honest
Good product copy for NIP-BE: Nostr BLE Communications Protocol names portability. It tells you whether another client can open the object, whether a relay or app-specific convention is required, and what might fail when you leave the original product.
What this page does not promise
NIP-BE: Nostr BLE Communications Protocol does not make a niche feature portable just because it uses Nostr events. Portability begins when another client can parse the object, recover the context and show a useful experience without a private API. Read NIP-01, NIP-77 and look for second-client evidence before treating the format as settled.
Read it as a field test
Start NIP-BE: Nostr BLE Communications Protocol with interoperability. If unrecommended, draft, read-message, EVENT, EOSE cannot travel into another useful interface, the feature is still mostly an app convention. Read NIP-01, NIP-77 and look for public examples before assuming a specialized NIP has become a stable product surface.
Where the standard earns trust
The source links give you places to test the interpretation in public: PR #1979, NIP-01 Basic Protocol, NIP-11 transport discussion. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-BE source is the anchor for exact wording, and NIP-BE commit history shows how that wording moved over time. The strongest secondary clues here are PR #1979, NIP-01 Basic Protocol, NIP-11 transport discussion. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-BE: Nostr BLE Communications Protocol: first the human promise, then unrecommended, draft, read-message, EVENT, EOSE, then the implementation record, then the real-world failure case. That order keeps NIP-BE useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can a second app open the object and make it useful, or does the first product still carry the real meaning?
- Which part is standardized in
unrecommended,draft,read-message,EVENT, and which part remains a convention, server policy or UI choice? - What happens when the app, relay, local transport or handler that created the object is gone?
What to verify before you rely on it
- Find
unrecommended,draft,read-message,EVENT,EOSEin the official file and check where the UI exposes the same concept. - Read NIP-01, NIP-77 as context before treating NIP-BE as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-BE: Nostr BLE Communications Protocol in that order: Official NIP-BE source for the current wording; NIP-BE commit history for the change record; PR #1979, NIP-01 Basic Protocol, NIP-11 transport discussion for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
