A local bridge between your browser and your Nostr signer

One protocol, two ways to connect

Wi-Fi uses a local WebSocket connection. Bluetooth uses a GATT connection to the phone. Both carry the same authenticated session and encrypted request format, called nwlan/2.

The signer displays a pairing code. The browser reads or pastes that code, verifies the signer's transport key, and asks to pair. You approve the connection on the signer. Pairing does not automatically authorize every operation: the signer's permissions still apply, along with the extension's website permissions.

The connection uses transport keys separate from your Nostr identity. A new session gets its own encryption and authentication keys. Closing the connection, changing accounts or revoking access invalidates pending work. The extension does not silently switch to another signing key when the phone disconnects.

A proposal other applications can implement

We have written an experimental protocol draft with pairing formats, authentication transcripts, transport mappings, replay rules and public test vectors. It is an unnumbered proposal, not an accepted NIP.

The draft reuses the request objects familiar from NIP-46, with a different local transport envelope. It does not require applications to copy the Nostr WoT interface. A compatible client could be a desktop app, an extension or another native application.

The existing NIP-BE describes BLE communication between Nostr clients and relays. Our proposal addresses communication with a signer and uses a different handshake and frame format. These are distinct protocols.

What is ready, and what still needs testing

The browser client and wallet session have automated interoperability tests for signing, encryption, approval and revocation. That is useful evidence, but it does not replace testing Bluetooth on real phones or implementing the protocol independently. Browser support and mobile background restrictions also affect availability. The current browser connection lives in an extension tab, which must remain open; its transport key is kept only in memory.

The draft lists a replay-cache retention edge case that needs correction before full conformance is claimed. It also states the security limits: local connectivity does not prove physical proximity, observers can see traffic timing and size, and this version does not provide forward secrecy. Session separation prevents cross-session replay; it is not a ratchet.

Treat this as developer work in progress. The feature is opt-in, and availability depends on the particular extension and wallet build. This post does not announce availability in every browser store.

A shared SDK is the next step

A small @nostr-wot/local-bridge package would let applications reuse pairing validation, transcript construction, session state and BLE framing. Browser WebSocket and Web Bluetooth adapters can sit alongside it, while native apps provide platform-specific listeners and permission handling.

The package should reuse existing Nostr cryptography and signing contracts. It should not contain a second wallet, permission database or copy of the application UI. Migrating the extension and wallet onto the same tested core would reduce duplicated protocol code and give other implementers a practical starting point.

That package is a proposed next step, not an npm release announcement. Feedback on the draft, independent implementations and physical-device interoperability results will help determine what should become stable.