FAQ

Do I need to make a Bitcoin transaction to use OC Lock?

No. Identity mode (the default) requires zero on-chain transactions. Bitcoin is used only to prove you control an address, via a BIP-322 signature you sign once per browser. Payment mode is opt-in and only used when the vault creator explicitly charges sats for access.

Which Bitcoin wallets work?

Any wallet that supports BIP-322 signMessage. The app auto-detects UniSat, Xverse, and Leather. For everything else (Sparrow, Coldcard, Bitcoin Core, etc.), paste the signature manually.

Where is my device key stored?

In your browser's IndexedDB. It never leaves. If you use OC Lock on multiple browsers or devices, each gets its own key, and each registers a separate device record on Nostr under the same Bitcoin address.

What happens if I lose the browser that held my device key?

Envelopes addressed only to that specific device become unrecoverable from any other device. On a new browser, register a new device and have senders re-encrypt if the messages were important. Rotation is cheap — one BIP-322 signature.

Can an attacker who sees my share link decrypt the message?

No. The share link contains the envelope, but decryption requires the recipient's X25519 device secret, which lives only in their browser. The link is useless to anyone else.

What does the Bitcoin network actually see?

Nothing, in identity mode. There are no transactions. In payment mode, the network sees a normal payment from the unlocker to the vault-specified address. The vault itself is not anchored on-chain.

Is the sender anonymous?

Not by default. The envelope includes the sender's Bitcoin address in plaintext so the recipient can verify who sent it. For sender anonymity, sign from a fresh address with no tx history — but you lose the identity binding. Protocol-level sender anonymity (mix-style) is out of scope for v2.

Why Nostr for device records?

Nostr relays give us an addressable, permissionless, replaceable event store keyed by a tag — perfect for "publish a device record under my Bitcoin address." The authenticity guarantee comes from the embedded BIP-322 signature, not from Nostr itself, so a malicious relay cannot forge records.

How does this layer with OrangeCheck?

A device record contains a BIP-322 signature over a message that commits to a Bitcoin address — structurally similar to an OrangeCheck attestation. Senders can require recipients to hold an OC attestation meeting thresholds (e.g. ≥ 100k sats / ≥ 30 days) before encrypting — a sybil filter on your inbox.

Is this forward-secret? Post-quantum?

Not fully. Device-key rotation provides coarse-grained forward secrecy. For per-message ratchet FS, use Signal. For post-quantum, we'd need to wrap content_key in Kyber; it's on the v3 list.

Can I use this for files, not just text?

Yes. The composer accepts drag-and-drop or file-picker selection. Attach a single file and the envelope payload is the raw file bytes; attach multiple files and they're bundled in an oc-lock/archive/v1 wrapper (documented in /docs/envelope) before encryption. The reader auto-detects the wrapper on decrypt and offers per-file download plus a "download all" action. Total payload after archive framing must fit under ~256 KB to survive URL-fragment transport; larger files need off-chain delivery (IPFS, a shared drive, etc.) with the envelope holding only the link.

What if Nostr relays censor device records?

Lookup queries three or four public relays by default. If all of them censor you, publish to a relay you control — or even self-host. Because the authenticity proof is the embedded BIP-322 signature, any relay works; there's no need to trust a specific one.

What if a Nostr relay forges a device record?

It can't get away with it. The web client runs every fetched device record through a BIP-322 verifier against the claimed Bitcoin address before adding it to the candidate set. A forged record (attacker-controlled device_pk, purporting to be bound to someone else's address) won't have a valid binding_sig — the envelope sender sees a visible rejection and refuses to encrypt. Only records whose embedded signature actually verifies against the claimed address are used.

How does rotation work with pending envelopes?

Rotating invalidates only envelopes addressed to the old device_pk. New envelopes encrypted after rotation use the new key. There's no cross-key migration — senders always encrypt to the currently-published device record.

Can a sender prove they sent a specific envelope?

Yes. The envelope's sig.value is a BIP-322 signature by sig.pubkey (the sender's Bitcoin address) over the envelope id. Anyone with the envelope can verify authorship offline. This is non-repudiable unless the sender's private key is compromised.

What happens if a sender uses a wallet that doesn't return a deterministic signature?

Nothing breaks at the protocol level — BIP-322 signatures don't need to be deterministic; verification uses the raw signature. The only place determinism matters in OC Lock is the derivation of the Nostr authorship key from the device secret, which uses HKDF (always deterministic).

How do I receive a vault shared as a QR code?

On the /unlock or /app → Open screen, click scan qr — the browser asks for camera access and opens the back camera. Point it at the QR. For single-code envelopes it decrypts as soon as the code is recognized. For multi-part envelopes (anything > ~2.9 KiB at error-correction M), the scanner shows a N / total parts captured counter and a set of tile indicators; sweep across each QR in the grid until every tile fills, and the envelope auto-parses. The jsQR library runs entirely in your browser; no camera frames ever leave the device.

Can I use this without the app?

Yes. Install @orangecheck/lock-core and call seal() / unseal() from any Node, Deno, or browser context. The quickstart has examples. The app is just one reference client.

What happens if I open a share link before registering a device?

The app will tell you. Instead of silently failing, /unlock surfaces a "register first" empty-state, stashes the envelope in localStorage, and routes you to /app to register. When you come back, the envelope picks up where it left off and decrypts as soon as your new device is bound.

What if I open a share link on a browser where my device is locked?

The decrypt flow detects that the matching device is locked and pops an inline unlock dialog right where you are — no bounce to the device manager. Enter your passphrase, the decrypt retries automatically, and the unwrapped secret stays cached in RAM for the rest of the tab session.

How long does an unlocked device stay unlocked?

Unwrapped secrets sit in RAM for 15 minutes of inactivity, after which they're zeroized automatically and the device returns to the locked state. Sixty seconds before that happens you'll see a toast with a keep unlocked action that resets the timer. The cache never touches disk; closing the tab also clears it immediately.

Can I change my device passphrase without re-registering?

Yes. In the device manager, every passphrase-encrypted device has a change passphrase button that runs a two-step flow: confirm the current passphrase, then set a new one. The underlying device secret and public identity don't change, so all existing envelopes addressed to the device remain readable. If you cancel at any point, the original vault is left untouched.

Does the app remember envelopes I've sent, not just received?

Yes. The inbox has a received / sent tab strip. Each sent entry is logged with the recipient address, timestamp, and a copy-ready share URL so you can re-share without rebuilding. Plaintext is never stored for either direction — only envelope metadata. Clearing history is scoped per direction so you can wipe sent-only or received-only without affecting the other.

What's the difference between seal/open and chat?

Seal/open is the one-shot primitive: you encrypt a message to a recipient address and hand them a URL they open once. It's great for "here's a document, here's a password, here's a one-time note." No back-and-forth expected.

Chat is that same primitive running continuously over a persistent transport. Your Lock device subscribes to Nostr for kind-1059 events tagged to your chat inbox; incoming messages decrypt automatically, go into a thread keyed by the sender's Bitcoin address, and stay there as scrollback. Same crypto, same identity, same wallet signatures — just automated delivery and a conversation view. Full technical breakdown at /docs/chat.

Do I need a separate account for chat?

No. If you have a Lock device registered, you already have a chat inbox — the device's Nostr chat pubkey is derived deterministically from the device_sk. The address of your inbox is computable from your public device record, so anyone who can look you up to send a Lock envelope can also DM you.

Is chat E2E encrypted?

Yes. Every message is a standard OC Lock envelope (X25519 ECDH → HKDF → AES-256-GCM to the recipient's device_pk) wrapped in a Nostr kind-1059 event signed by a throwaway pubkey. Relays only see ciphertext + the recipient's chat pubkey; they cannot read content, forge senders, or link the sender's stable identity to the message.

What does the Nostr relay see when I chat?

An event with kind=1059, an ephemeral Schnorr pubkey (different for every message), a p tag with the recipient's chat pubkey, and an opaque base64 blob as content. The relay cannot tell who sent the message, what it says, or which conversation it's part of. The created_at is rounded to the minute to reduce timing correlation with any visible action the sender just took.

Can I use chat without a browser wallet?

Yes, but messages will be unauthenticated — the recipient can decrypt but has no BIP-322 signature proving you sent them. The chat composer warns you if no wallet is detected. Most wallets that support signMessage work out of the box (UniSat, Xverse, Leather).

Will chat work on my other devices?

Yes, going forward. The sender's client looks up every device record published under their own Bitcoin address and gift-wraps a self-addressed copy to each one — so a message you send from browser-A is automatically delivered to browser-B (and any other device you've registered under the same address). Likewise, the recipient's multiple devices all receive their own gift-wrap because the sender fans out to every verified device record under the target address. There's no server-side scrollback — messages older than what the relays still hold (typically days to weeks) don't sync retroactively when you register a brand-new device.

What about groups, typing indicators, read receipts?

Not in v1. Groups require sender keys + a membership change protocol; typing/read receipts are metadata leaks we haven't decided to accept by default. Tracked on the roadmap.