@bwalletx/connect 0.5.3 → 0.5.4

package/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## 0.5.4 (unreleased)
+
+- **Connect is fast.** A wallet that is present now resolves at once: the extension answers `brc100:requestWallet` synchronously, and `window.CWI` (in-app browser) is taken straight away instead of after the wait. The wait for "nothing here" before the pairing QR drops from 1200 ms to 300 ms (`DEFAULT_DISCOVER_MS`); in a bWalletX frame the XDM probe now starts in parallel. `discoverWallets` stops waiting 50 ms after a wallet has announced. Measured in Chrome: pairing modal 1.24–1.34 s → 0.33–0.34 s after the click.
+- **`onStatus`** on `signInWithBwalletX` / `connectBwalletX`: `'finding' | 'opening' | 'pairing' | 'signing'`, so the button can say "Opening your wallet…" the moment it is clicked.
+- **`prewarmBwalletX()` / `bindPrewarm(el)`**: on hover, focus or touch, send a prompt-free `isAuthenticated` so a sleeping extension worker starts reopening the wallet before the click (about 0.5 s off a cold Connect). `<bwalletx-signin>` binds it automatically.
+- **Security: relay role claims for the site (b-Aware 26 Oct 2026, N3-1/N3-2).** `pairBwalletX` now opens the relay channel with its own random site claim and stores it with the pairing (`sc`); every reconnect sends it, so someone who learns the channel ID can no longer replace your socket or lock you out. It also sends `wc`, the SHA-256 of the wallet claim only the QR can produce (`walletClaimFor(channel, site pubkey)`), so nobody can take the wallet role before the phone scans. Pairings stored by older versions get a claim on their next reconnect. **Upgrade before 30 Nov 2026**: after that the relay refuses new channels without a site claim. See "Relay claims" in the README.
+
 ## 0.5.3 (unreleased)
 
 - **Phones get "Open bWalletX", not a QR.** On a touch device (`isTouchDevice()`), `pairingModal()` no longer shows a QR the user would have to scan with the same phone. It shows **Open bWalletX**, a link to the pairing universal link (`https://www.bwallet.space/pair?…`, the iOS universal link / Android app link the app already handles), plus **Use web.bwalletx.com instead** (copies the link and opens the web wallet to paste it), and the match code. The page keeps waiting on the pairing channel, so the user approves in the wallet and comes back. Desktops still get the QR. Force either with `pairingModal({ mode: 'qr' | 'app' })`.

package/README.md

@@ -326,6 +326,10 @@ The pairing is saved under `bwalletx.connect.pairing.v1` in `localStorage` by de
 
 The phone sends a plain `hello` and then, as soon as the user taps Connect, an encrypted `ready`. An async `onmessage` handler that is still deriving the key from `hello` when `ready` arrives drops `ready`, and pairing never finishes. This package handles frames one at a time in arrival order (`inOrder`). `test/pair.test.ts` reproduces the race.
 
+### Relay claims
+
+Since 0.5.4 the site side sends a role claim to the relay on every connect, and a digest of the QR-bound wallet claim when it opens a channel. Only the socket with your claim can take the site role, and only a phone that scanned your QR can take the wallet role. The relay (relay.bwallet.space) keeps a compatibility window for older sites and wallets until **30 Nov 2026**: until then a site without a claim can still open a channel and an older wallet can still join one. After that date the relay refuses both, so update `@bwalletx/connect` (or a copied `protocol.ts` + pairing code) before then. Sites that copied the pairing code must send `claim` on every site socket (keep it with the pairing) and `wc = claimDigest(await walletClaimFor(channel, sitePub))` when opening a new channel.
+
 ## One script tag
 
 ```html