Dont need to deprecate. But I see what you mean, re inconsistent UX. You can have apps that take advantage of it, and apps that dont. Ultimately nostr is permissionless dev, so some apps do some things, others do other things. Client/client standards can only go so far, at some point, when functionality is needed.
Discussion
I guess it depends on the proposal, i haven’t seen a convincing one yet
How do we solve this for wider adoption?
We have to decide if logging in with nostr is a desire-able thing to have. The ecosystem seems to be moving to passkeys, i don’t see why we necessarily need npub identities for login. There are many reasons you wouldn’t want that: privacy, etc.
Logging in with nostr was a big plus for me but I’m not a normal use case.
What are passkeys?
https://developer.apple.com/passkeys/
https://developers.google.com/identity/passkeys
https://blog.google/technology/safety-security/the-beginning-of-the-end-of-the-password/
So a private key is stored locally on device and the corresponding public key is stored in the server.
That’s pretty much just Nostr sign-in.
The only difference is that passkey approach generates a new key for every app. It’s like using a different private key for every nostr client.
They’re login tokens that are encrypted on your device and tied to a master identity.
Passkeys are utter trash in implementation but the underlying concept is good
npub login is flawed because it can’t support multi identity and is non-private by design
And also they don’t use obscure shit like BIP304 signatures so they can be put onto a secure element
All the "hardware wallet" implementations for Bitcoin show that you can make a secure element for BIP340 just fine.
Specialized SEs != TPMs in computers, SEs in phones, etc
Ah yes correct.
BIP340 are Schnorr signatures?
Section: C.4.3 EC Schnorr
"If a TPM supports ECC, it should support the TPM_ALG_ECSCHNORR scheme."