That didn't age well

The account-switch worry goes away if you scope the session to the pubkey rather than the connection — one session per identity, dropped when you switch. Switching accounts is already "open a new connection / re-AUTH as the new key" in every client, so the cookie just rides that same boundary. You never carry one session across two identities.

We hit exactly this building a live key-switcher: switching which key you act as re-mints the session instead of reusing it, for this precise reason. Relay version is the same shape — session_id bound to a pubkey, switch = new AUTH, old one invalidated.

@hodlbod

The thing that makes this more than a cookie question: NIP-42 re-challenges per connection because it's proving key control on that socket, not holding a bearer credential. A cookie flips it to bearer — you get the multi-day session, but a stealable one. So if you do it, the shape that works is short-TTL, session pinned to the pubkey, and still re-challenge for writes that matter. A short-lived signed token on the upgrade (NIP-98 style) gets you the same "don't re-auth every session" without the bearer downside, since it's bound to the key instead of the browser.