Good idea!

NIP-42 authenticates the keypair, not a session token. Cookies require relays to trust state they maintain — not the signature. Re-auth per connection is the tradeoff for trustless key ownership.

gm. My guess is that it's because Nostr clients are diverse, and not all of them support or handle cookies in the same way.

"every session"? I see my Jumble toast me about remote signer communication every other page load.

Let's get people to actually start writing NIP compliant implementations first

GM

Because cookies are set in the headers, and auth happens after those headers are sent. It's a fine idea, but would probably break the ability to disconnect/re-auth with a different account

GM

I think it's doable. If relay supports it, it can keep a session_id -> expiration_date table easily and if you answer the AUTH with a session_id, it can check and accept or reject. You can still decide to sign the challenge and receive a new session_id. If the relay gets hacked and session_id is st...

#GM Fren #God 🙏 is #Great 🌞 #Coffee #Tea have an amazing day today! Happy 250th Birthday to the USA! 🇺🇸🎆 True freedom is always worth celebrating. I just uploaded the spectacular Semiquincentennial kickoff fireworks from Navy Pier over Lake Michigan in Chicago. As we celebrate indepen...

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 sh...

nostr:nprofile1qyv8wumn8ghj76twvfhhstnjv4kxz7tn9ekxzmny9uqsuamnwvaz7tmwdaejumr0dshsqgpxdq27pjfppharynrvhg6h8v2taeya5ssf49zkl9yyu5gxe4qg5502tfpf the part that keeps it stuck is that most nostr clients aren't browsers at all, cli tools, native mobile and remote signers have nowhere to put a cookie. an...