i think the problem has to do with a misunderstanding of client devs about how sockets work

the socket is a modal interface. it has a state, ready, and there are requests and responses... the way the nip-01 is written this categorization is not clear, so i can understand how this problem arose

it is very clear when you read the code that nostr:nprofile1qyd8wumn8ghj7mr0vd4kymmc9enxjct5dfskvtnrdakj7qg6waehxw309ac8junpd45kgtnxd9shg6npvchxxmmd9uq3kamnwvaz7tmjv4kxz7fwwajhxar9wfhxyarr9e3k7mf0qyfhwumn8ghj7am0wsh82arcduhx7mn99uqzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vac7xr2j wrote for auth - a SOCKET is authed, not a REQUEST

if the client wants to make a request, and for example, the relay says it's "write-restricted" as in nip-11 (i need to add this to realy because i think this is relevant, write-restricted should also be part of the complex of elements in AUTH because what that means is "auth-required" to WRITE.

so i might go further to suggest that in the nip-42 text it should also mention that "restricted-writes" or whatever it is called, indicates that the sockets are modal upon AUTH, as in, when a socket demands AUTH it is because the request is "auth-required" which can be both read (req/count) and write (event)