I'm skeptical about most of the Pros listed:

> Multiple keypairs/identities are not needed
- that's just implementation detail, like generating tokens in oauth etc

> Access tokens are only useful for authorization and are generally short-lived, they don't leak any permanent information.
- not sure which parts of nip46 leak anything, can you provide details?

> Signer events are now "private" between clients and signers, and can't leak user activity such as note decryption when opening a new client.
- this one is valid concern

> No relay, no relay to trust
- most nip46 providers will host their own relay for many reasons, and even if they use a third-party relay - they will only recommend one they trust, so if you trust a provider, you probably trust the relay

> Http attack surface is well understood
- need more details and maybe examples here

> CORS could possibly be used as a security advantage for web clients
- need details and ideas of where and how

> Reduces signing server dev complexity
- you won't implement oauth yourself, you'll use a library, but then you can just use a library to implement nip46

> Full OAuth2 and identity management infrastructure already exists
- which of them could I start using tomorrow to use with Coracle or Snort on mobile? This might be true for corporate world, not much for individuals

> Since clients connect directly, network/http requests can be audited easily
- audited for what? all requests are signed, the only thing lacking with nip46 is peer's IP address, which is only useful for privacy violations of good users, since bad people hide their IP anyway

> Reduces client complexity and deprecated encryption spec
- you will use a library in both cases, so complexity is comparable. nip04 is bad, agreed.

 

 I appreciate your feedback and I intend to revisit this with better scrutiny when I a little more time read & think, as I still believe a direct-to-signer model like this would be ideal. 

>  not sure which parts of nip46 leak anything, can you provide details?
If the encryption keypair ever leaks, event sniffers that stored your previous messages will be able to decrypt them in the future. This simply isn't a concern if they can't be sniffed in the first-place. I think I'm mostly arguing surface area here, since dms are using the same encryption anyway, its more about the possibly leaky keypair. 

I think I saw you mention nip42.
Were still trusting relay servers to follow the rules, and with signers I want an option that can avoid that if possible. I think relay servers should pretty much be trusted as dumb databases.

Also, I am rolling my own OAuth2 but it's part of my web framework to your point actually.  

 As discussed, nip46 can't work in practice with untrusted relay, just treat it as part of the signer service.