Happy to extend NWC to include those features if that is all it needs.
Discussion
Needs a total rewrite for the handshake, not to mention the server handlers, it's literally leftover browser extension slop that never considered the bigger picture of ad-hoc and service connections
Keep letting that NIP repo access go to your head though, muh numbers...
yeah, wen auth ack
Auth? I'm intrigued. Describe what you have in mind
nip 42 flow forces clients to often have to resend events at the beginning of opening a websocket. there should be an ack so the client can just send it once after they know if the relay has allowed their storing of events, just once.
hmm, they'd have to send some event in any case in order to be ack'd, otherwise the relay can't know who's socketing... only alternative I could think of is pro-active auth, fail/retry is probably the simplest
currently, the only way the protocol acknowledges valid auth, sort of, is by an OK/CLOSED message (EVENT and REQ, respectively) with an errror. the ack should include a human readable part of the response that indicates, eg "authed to read/write; role name X of policy https://relay.url/policy.md%22
yea some standard GFY codes that could infer scope would probably help, looks like there's a human readable but is only appended after a single ambiguous prefix
yeah, specifying the policy also part of nip-11 as well, so a relay should be configured to telegraph to users what the policy is. this is too complex to use machine encoding. there is two parts. one part can be precisely described, such as event limits, event kinds, etc etc, the other half is the human-curated part of the policy.
any rejection of query or event publish will specify the policy violation it invokes.
you can be whitelisted to use a relay, but try to send events or queries that are forbidden by the relay, and it rejects them. so the ack is not a blanket permission, it is just an acknowledgement that the user has a role defined in the policy and they are restricted by the rules associated with the role.
the ack's purpose is just to prevent the waste of bandwidth and improve that initial load time, which is important, in my opinion. well written clients will proactively query and cache results that the user will want to see, to further improve UX.