Re: challenge string. I feel there is an obsession with trying to protect everything from all of these theoretical MITM attacks. By including the host/relay, you resolve the worst concerns imo.
Discussion
I’m with you. Can always be a hot fix or improvement later if issue.
Security is just very hard. And state based actors and centralised services (even CDNs) are a real threat going forward.
Be nice if we can eliminate risk from day one.
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.