Bark

The protective outer layer of Heartwood.

Bark is a minimal NIP-07 browser extension that signs Nostr events through a remote signer via NIP-46. No keys in the browser. No accounts. No bloat.

What it does

• Signs Nostr events via NIP-46 remote signing (NIP-07 interface for web apps)
• Works with any NIP-46 bunker — nsecBunker, Amber, or your own signer
• Switches Heartwood identities — imports Heartwood's per-identity bunker URIs and switches by selecting the right bunker instance
• Bridge-friendly — works with Wi-Fi devices, Heartwood daemons, or relay-to-serial bridges for tethered low-cost hardware
• Self-sovereign — keys live on your signer hardware, never touch the browser

What it doesn't do

• No wallet, no Lightning, no zaps
• No local key storage
• NIP-44 encrypt/decrypt forwarded to remote signer

Install

1. Download the package for your browser from the latest GitHub release
2. Extract the zip
3. Open chrome://extensions/, enable Developer mode
4. Click "Load unpacked", select the extracted directory
5. Click the Bark icon, enter a Heartwood/bridge address or paste your bunker URI

Build from source

git clone https://github.com/forgesworn/bark.git
cd bark && npm install && npm run build:all

Then load the relevant output:

• Chromium, Chrome, Brave, Edge: dist/
• Firefox: dist-firefox/
• Safari: dist-safari/ through Apple's Safari Web Extension conversion flow

Package all browser builds with:

npm run package:all

Run the release checks with:

npm run verify
npm run e2e:chromium
npm run e2e:deterministic
npm run e2e:approval

npm run e2e:chromium includes the deterministic local NIP-46 relay/signer smoke and approval popup flow. npm run e2e:deterministic runs only that CI-friendly signer path. npm run e2e:approval runs only the deny, allow-once, trust-site, and protected-kind approval checks.

Run an optional live relay/signer smoke with a real approved bunker URI:

BARK_LIVE_BUNKER_URI='bunker://...' npm run e2e:live

That test seeds Bark with the bunker URI directly, trusts only its temporary localhost test origin, then verifies getPublicKey, relay visibility, and a real signEvent through the connected signer. Set BARK_LIVE_CLIENT_SECRET=<64-hex-secret> as well if you want the signer to remember the same Bark test client across runs.

Full setup guide

For a complete walkthrough — firmware, bridge, provisioning, and Bark together — see the Heartwood + Bark setup guide.

For the release hardening test matrix, see E2E hardening.

Works with any NIP-46 bunker

Bark works as a standard NIP-07 provider with any NIP-46 bunker. Paste a bunker:// URI from nsecBunker, Amber, or any compliant signer. The signing flow (getPublicKey, signEvent, nip44.encrypt, nip44.decrypt) works identically regardless of the backend.

Identity features (derive and list) require Heartwood. When you pair by a Heartwood HTTP address, Bark also imports the per-identity bunker URI manifest from /api/identities. That endpoint can be a Wi-Fi Heartwood appliance, a Pi daemon, or another Heartwood-compatible host sitting in front of cheap tethered hardware. The current Heartwood model is that each identity has its own bunker URI, and selecting a persona in Bark selects the matching bunker instance.

Sapwood-created bunker slots work by pasting their bunker:// URI into Bark. Heartwood remains the signer source of truth; Bark only stores the approved connection strings and the Bark client auth secret.

Cheap hardware and bridge mode

For hardware without Wi-Fi, Bark should not talk to the board directly. The heartwood-bridge daemon is the network-facing NIP-46 component: it connects to relays, pumps encrypted requests over USB/serial, and republishes the signed responses. The bunker URI can point at public wss:// relays or a loopback ws://localhost relay exposed by the host daemon. Sapwood provisions and manages that hardware path; Bark consumes the resulting bunker:// URI or the HTTP pairing API exposed by the host daemon.

That keeps the boundary clean:

• Cheap board: holds keys and signs.
• Bridge daemon: relay-to-serial transport, no signing key material.
• Sapwood: provisioning, slots, policies, and management.
• Bark: browser NIP-07 provider and bunker selector.

Site trust and approvals

Bark asks before sharing identity, signing, or encrypting/decrypting for an unknown site. The approval popup can allow a request once or trust the site for routine future requests. Protected event kinds such as profile metadata, contacts, and relay lists continue to ask unless you add an explicit site kind override in the popup policy settings.

Heartwood RPC extensions

When connected to a Heartwood signer, Bark uses custom NIP-46 RPC methods for persona management. These are sent via BunkerSigner.sendRequest() over standard NIP-46 relay communication.

heartwood_list_identities

Returns all derived identities on the device.

• Params: none
• Returns: Array<{ pubkey: string, name?: string, purpose?: string }>

heartwood_derive

Derive a new identity from the device's mnemonic.

• Params: [purpose: string, index: string]
  • purpose — alphanumeric label, 1-64 chars (e.g. "nostr", "twitter")
  • index — derivation index as string, "0" to "1000"
• Returns: { pubkey: string, purpose: string, index: number }

heartwood_switch (legacy)

Latest Heartwood treats identity selection as per-connection, based on the bunker://<pubkey> target. Bark keeps this RPC available for older Heartwood builds and third-party callers, but the extension UI switches identities by switching Bark instances.

• Params: [pubkey: string] — 64-char lowercase hex public key
• Returns: Heartwood-specific status for the current connection

Comparison with other NIP-07 signers

	Bark	Alby	nos2x	Remote NIP-07
Key storage	None (remote signer)	Browser or Alby Hub	Browser	None (Amber)
NIP-46 backend	Any bunker	No	No	Amber only
Derived identities	Unlimited (Heartwood)	None	None	None
Self-sovereign signing	Yes	Software only	Software only	Phone (Amber)
Size	Focused, 1 runtime dependency	Large extension + hub	Small extension	Small extension
Lightning	No	Yes	No	No

Bark is not an Alby replacement. It is a focused tool for people who want self-sovereign Nostr signing with optional derived identity management.

Privacy

See PRIVACY.md. TL;DR: Bark stores connection, instance, signer health, and policy state locally. No analytics, no tracking, and your signing keys never leave your signer.

Part of ForgeSworn

For internal architecture details, see ARCHITECTURE.md.

Bark is part of the ForgeSworn open-source ecosystem for sovereign identity and commerce on Nostr and Lightning.

Part of the ForgeSworn Toolkit

ForgeSworn builds open-source cryptographic identity, payments, and coordination tools for Nostr.

Library	What it does
nsec-tree	Deterministic sub-identity derivation
ring-sig	SAG/LSAG ring signatures on secp256k1
range-proof	Pedersen commitment range proofs
canary-kit	Coercion-resistant spoken verification
spoken-token	Human-speakable verification tokens
toll-booth	L402 payment middleware
geohash-kit	Geohash toolkit with polygon coverage
nostr-attestations	NIP-VA verifiable attestations
dominion	Epoch-based encrypted access control
nostr-veil	Privacy-preserving Web of Trust

Licence

MIT