One other thought here.. it’s possible to use this for Relay Auth by sending the same in the websocket http connect header.
I don’t believe websockets should live longer than 30 minutes in the real world at scale (see LinkedIn, Facebook, Netflix, other engineering talks).
Perhaps it can even replace it.
Yep seems like a better way to do NIP-42 imo
I was advocating for exactly this and agree 100%. An optional header for NIP-42 is what we proposed.
The pushback I got was:
1) adding a second way to do AUTH is unnecessary protocol bloat.
2) web clients can’t send a header with a websocket connection
3) without a challenge string it doesn’t protect against MITM
I don’t agree with 1 or 3 and perhaps you have guidance on 2.
It is WAY better to do AUTH in a header if the socket is going to force you to do it on connection anyway. Relieves both clients and relays from having to address the REQ/AUTH race condition and prevents us from having to open and upgrade the connection just to fail AUTH.
I am totally behind this effort but tried once and failed.
