fix: an identity signs a named kind, and a device approval answers a request

The desktop main process builds every transcript itself from fields
(transcripts.js) and signs no raw bytes; the page's identity has the same
contract (crypto.js transcriptFor). The keyring seals no bundle while browser
access is off. On the node, device_add must redeem a pending request filed by
the same keys, and device_revoke is signed under its own prefix
(meshbay:device_revoke:v1), so a retirement signature admits nothing.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 3 insertions, 1 deletions

diff --git a/packages/meshbay-client/src/preload.js b/packages/meshbay-client/src/preload.js
index 469bc48..e9c34d2 100644
--- a/packages/meshbay-client/src/preload.js
+++ b/packages/meshbay-client/src/preload.js
@@ -98,7 +98,9 @@ contextBridge.exposeInMainWorld('meshbay', {
     sealRecovery: (u, n, m, name) => ipcRenderer.invoke('keys:seal-recovery', u, n, m, name),
     markSealed: (u, n, fp) => ipcRenderer.invoke('keys:mark-sealed', u, n, fp),
     fingerprint: (u) => ipcRenderer.invoke('keys:fingerprint', u),
-    sign: (u, n, bytes) => ipcRenderer.invoke('keys:sign', u, n, bytes),
+    // A kind and its fields, never bytes: the main process builds what it
+    // signs (transcripts.js).
+    sign: (u, n, kind, fields) => ipcRenderer.invoke('keys:sign', u, n, kind, fields),
     shared: (u, n, peer) => ipcRenderer.invoke('keys:shared', u, n, peer),
     playlistKey: (u) => ipcRenderer.invoke('keys:playlist-key', u),
     browserAccess: (u) => ipcRenderer.invoke('keys:browser-access', u),