lightning-browser-extension

lightning-browser-extension copied to clipboard

Intro

More and more sites continue to build on nostr. Nostr is

https://github.com/nostr-protocol/nostr The simplest open protocol that is able to create a censorship-resistant global "social" network once and for all. ... it is based on cryptographic keys and signatures, so it is tamperproof...

which means that it requires users to have one or multiple sets of public-private keypairs. (one for each identity)

Since the browser extension is already connected to your node we could make use of the same cryptographic keypair to sign nostr messages. That would remove the need to separately backup nostr keys.

Technical analysis

Lot's of the UI is already there (to enable sites and sign messages) and could potentially be reused to handle window.nostr API calls in the same way we currently handle window.webln calls.

The following API specs would need to be implemented in the provider:

async window.nostr.getPublicKey(): string // returns your public key as hex
async window.nostr.signEvent(event): Event // returns the full event object signed
async window.nostr.getRelays(): { [url: string]: RelayPolicy } // returns a map of relays
async window.nostr.nip04.encrypt(pubkey, plaintext): string // returns ciphertext+iv as specified in nip04
async window.nostr.nip04.decrypt(pubkey, ciphertext): string // takes ciphertext+iv as specified in nip04

There already is an implementation available here:

https://github.com/fiatjaf/nos2x

Questions

• How would we handle that for custodial solutions? (Alby Accounts, LNBits, etc)
• How can we derive nostr keys from the nodes private key?

Links

• nostr
• nostr Browser Extension
• nostr NIP07

@fiatjaf Is there any chance to get your feedback on this idea? The main questions for you are:

• Do you think deriving a nostr key from the node key material is a feasible way to do this?
• If yes: how could we create a nostr key from various backends (LND, LNDHub, LNBits, etc)?
• Is signing a message (those APIs would already be available) a way to create reproducable key material for nostr keys?

@reneaaron:

• to derive a key I think you can just use the same method you are using for deriving the lnurl-auth keys, it's not the best thing, but it will work. I just think you should expose that field to users in case they want to backup it or use it in some other client.
• idem.
• no, that is not available, you'll have to sign the events on the extension itself, which is fine since you already have the key derived from step 1.

Awesome, I'll dig into that. Thanks for your quick feedback!

To my knowledge lnurl-auth works by signing a message with the underlying node key (basically lncli signmessage), right? @bumi

https://github.com/getAlby/lightning-browser-extension/blob/master/src/extension/background-script/actions/lnurl/auth.ts#L125

For lnurl-auth Alby signs an arbitrary message DO NOT EVER SIGN THIS TEXT WITH YOUR PRIVATE KEYS! IT IS ONLY USED FOR DERIVATION OF LNURL-AUTH HASHING-KEY, DISCLOSING ITS SIGNATURE WILL COMPROMISE YOUR LNURL-AUTH IDENTITY AND MAY LEAD TO LOSS OF FUNDS!.

I was just reading into nostr keys in NIP-06 and stumbled upon m/44'/1237'/0'/0/0.

Would it make sense to re-use this derivation path here, too? While that probably wouldn't allow users to restore their nostr keys just by the node key itself there would at least be a reproducable way to generate nostr keys also for other extensions that might have a connection to your node and can sign messages. We could even support sub-accounts in future by deriving other keypaths like m/44'/1237'/0'/0/1 etc.

Let me know what you think!

I don't have opinions on these things. Whatever you do will be equally terrible because people will lose their keys anyway, so maybe don't worry too much.