I think using npubs for premium services auth is a mistake. Keys are disposable and should always maintain this property of being easy to throw away to start over effortlessly. When services are tied to a single npub, it’s harder to throw it away, especially if you always paid for that service for an extended period.
I don’t know what the solution looks like but I know it’s a mistake to treat npubs as some sort of permanent identifier.
Ethereum thinking leads to...
nostr:note19pzl5jqrzdw4evgq7es5rvqwres2cnpz0q480uzcc0jcz6j39k8qe4x3q3
Key migration is still an unsolved problem, it's perfectly reasonable to use npubs for paid services imo and the root problem should be addressed
Ya we need a way to associate a new key with the old one without revealing it to the world
I was working on that for my proposed nip41, i have to iterate over it again as it can be simplified, but it address how to set a new npub to migrate without revealing it
Is it possible to deploy a personal DNS type of solution for this? Similar to username NIP 05? That way your username remains tied to infinite npubs you specify?
Not a developer so curious if it’s even an option.
Yeah I’ve not been comfortable with the idea of a single account for all the web, no matter how convenient. One service gets hacked and bang goes all that data
If we had good multi-key management, this wouldn’t be as big of an issue because you could just swap keys on different services. I guess nsec.app already makes this somewhat easy to do, if more clients supported it
"logging in" with Nostr is quite different than logging in with a traditional account. When done correctly, the service or platform being accessed never touches your keys/credential/secret. This limits the blast radius of a hack significantly. Can't and shouldn't think of it the same way that you think of "an account"
My 2 cents is major app devs need to agree to stop allowing priv key logins (or at least hid them in a sub-menu) and only extension or bunker. But that would mean every iOS app would stop operation.
Yea I think there are two situations:
1) Nostr client login
2) Platforms that allow you to login with Nostr
Eventually #1 will be everything, but in the meantime there will likely be a lot of #2s. For #2 the platform just has to be able to prove you have ownership of your npub, which can be accomplished through DM
A hierarchy structure could work, with “master” and “sub-accounts”.
But then you can't throw away the "master"
Wouldnt need to would you? The subs would be the throw aways.
Being able to lose a key and needing to throw a key away are effectively the same thing. Without having keys that are impossible to lose, the idea is that we should treat all keys as a throwaway entity in our designs.
“…we should treat all keys as a throwaway entity in our designs.”
Yes
descriptors based on a seed work well for corn wallets
