The first framing that needs to be fixed here is your nsec is NOT a password. It’s a private key.

It’s useful to use the password analogy especially for people unfamiliar with it.

You use your private key to sign your events. Right now that’s it.

You don’t β€œauthenticate” with any server (this may change with some relays).

Not sure how a 2FA system would work here because you’re not authenticating into a system in the traditional sense.

I think key delegation and UX updates will help solve what I think you are describing.

Reply to this note

Please Login to reply.

Discussion

I understand that. My idea is to create the ability to generate a new revocable signing key based on your private key for each client or application.

this is just nip26 and it does not involve passwords

Right. So how do we generate our own keys to use on Nostrgram for example without exposing the nsec?

A new keypair is generated to be used in nostrgram.

Via NIP-26 a delegation token is signed by the original privkey.

That token allows the new privkey to sign certain events during certain time on behalf of the original privkey.

https://github.com/nostr-protocol/nips/blob/master/26.md

You still expose your nsec when you sign up the first time. I want to be able to generate a key pair myself not a token

You don't expose it.

You sign the delegation token with the original client where it's installed.

I don’t get it, Your private key is being used to login. How do you eliminate that part?

Ok, let's see it with an example:

Initial situation:

- you have a nostr client using a keypair.

- you want to use another nostr client but you don't want to assume the risk of introducing the privkey in the new client.

Here comes NIP-26 to help:

- you log in the new client with a brand new keypair (ideally the new client guides you to create this new keypair automatically)

- you create a token in the first nostr client, signed by the original privkey, that allows the new privkey to publish events on behalf of the original privkey (with some limits: event kinds, time, etc)

- you configure the delegation in the new client introducing the token.

- you can now publish from the new client signing with the new keypair, on behalf of the original keypair (the published event includes the token so that everybody can check that it's allowed)

Does it make sense?

But what client can I use offline to generate a delegation key?

You mean what nostr clients allow you to generate NIP-26 tokens while being offline right now?

None that I knew of, tbh.

Yes. So you are still exposing your nsec, that’s what I want #[4]​ to build into #[9]

Damus doesn't work offline.

Do you want Damus to be the "new client" that publish events on behalf of another keypair?

No. A client that can generate slave private keys from a master private key.

Apologies in advance if I get this wrong.

What it sounds like is building the equivalent of an xpriv.

You’d probably need some sort of offline signing device to do this like the Bitcoin wallets institute. The master key needs to live β€œsomewhere”.

On the web clients the NIP-07 carry the nsec and only takes in data to sign, never exposing the private key.

I’m not an iOS expert and don’t know how you’d do this with a native app.

No. It is like generating app specific passwords from a master password.