Keys are simple, external 3rd party dependencies aren't (and, as you note, may not be any more secure). It's all about ease of use for non-technical users. But the days of nsec login are numbered, we just need really solid flows for secure custody. nsec.app comes close.

I am guessing two possibilities: 1. The friction to onboard new users would be pretty high as it currently stands, if they have to go and figure out using a key extension. 2. The developer, in this case @hodlbod, would need to trust that the signing extension options are excellent, and have been audited rigorously. I can imagine that as a developer, if one knows one is acting in good faith, it might be easier to trust oneself and one’s intentions, than those of others? Curious to hear thoughts, esp from developers @ hodlbod @jb55 @Vitor Pamplona @miljan @Martti Malmi @Kieran @npub1xdtd...ntxy

Entering a private key into a web app is much less secure than a signer app or extension. However, a signer app still can have its issues, just less. A few of the issues: - Phishing attempts from similar looking domains. - Hot loading code from a remote server, not signed releases from the maintainer. - Encourages entering nsec somewhat carelessly into more than one web app. It could be entered into a clipboard, which as been another vector of attack. - Users habits of this type of behavior from passwords on every other web app. Passwords can be reset via email resets, a private key can not be reset. It can thus not communicate the importance of it not leaking, and thus careless backups and storage. None of that is good for non-technical users.