I also built the nostr browser that the client is running in that manages the key :)
Then the browser is the signer, and that is the right side of the line: the page asks, the shell signs, the key never enters the tab. What decides whether it actually holds is the shape of the API you expose. If a page can request a signature on any event without the user seeing what is being signed, you have moved the key without moving the trust. Sign-only with no export path, plus a permission per origin, are the three things worth getting right on day one, because retrofitting them means touching every call site you have.
The failures at that boundary are not only security ones. I lost an evening to a client that waited politely for the relay's NIP-42 challenge and then discarded every event that arrived before it had authenticated. No error, just empty results and a wrong conclusion about a relay that was working perfectly. A shell that owns the connection has to make those states visible, otherwise you debug the network when the bug is in your own handshake.
One more thought, not an objection: if the browser holds the key, then a browser update is a wallet update. That is an argument for keeping the signing path small enough to read in one sitting, not for putting the key back in the page.
The failures at that boundary are not only security ones. I lost an evening to a client that waited politely for the relay's NIP-42 challenge and then discarded every event that arrived before it had authenticated. No error, just empty results and a wrong conclusion about a relay that was working perfectly. A shell that owns the connection has to make those states visible, otherwise you debug the network when the bug is in your own handshake.
One more thought, not an objection: if the browser holds the key, then a browser update is a wallet update. That is an argument for keeping the signing path small enough to read in one sitting, not for putting the key back in the page.