Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add NIP 44 encryption support #2653

Closed
wants to merge 9 commits into from

Conversation

staab
Copy link

@staab staab commented Aug 11, 2023

I've added added for NIP-44 encryption and decryption so that users can access nostr features built on the new primitives.

Fixes #2652

  • feat: New feature (non-breaking change which adds functionality)

How has this been tested?

No testing yet

Checklist

  • Self-review of changed code
  • Manual testing
  • Added automated tests where applicable
  • Update Docs & Guides

@reneaaron
Copy link
Contributor

@staab Thanks for the PR! 🙌 Are there already any clients that implement NIP44?

@staab
Copy link
Author

staab commented Aug 12, 2023

Yep, Coracle does (private key login only right now for obvious reasons). Amethyst, Snort, and 0xChat are actively working on implementations.

@staab staab force-pushed the master branch 4 times, most recently from 404cf04 to abc683b Compare December 22, 2023 21:25
@staab staab marked this pull request as ready for review December 22, 2023 21:26
@staab
Copy link
Author

staab commented Dec 22, 2023

Ok, I think this is ready for review. It took a while to finalize the NIP 44 spec, but it was finally merged this week. I did add nostr-tools as a dependency, let me know if you'd like to copy the nip44 code into the project instead.

@reneaaron
Copy link
Contributor

Hey @staab, thanks again for the PR - there are currently some typescript checks failing:

https://github.com/getAlby/lightning-browser-extension/actions/runs/7303976512/job/20279852843?pr=2653

I'll try to get my hands on it this week and do some more testing.

nostr-tools should be fine to include as we also use it already in @getalby/sdk (which is also used in the extension)

mitata "^0.1.6"
nostr-wasm v0.1.0

[email protected]:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, why is mitata and nostr-wasm a hard dependency of nostr-tools?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about mitata, but nostr-wasm enables an optimization which speeds up signature validation. These should probably be, what, peer deps?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am always just a bit hesitant to have a wasm blob in the dependencies.hmm

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can extract nip 44 and drop nostr-tools, shouldn't be too bad

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any update on this? @bumi should we extract nip-44 from nostr-tools?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The wasm is fine, it's just Bitcoin's secp256k1 library compiled to wasm. It's faster. Check: https://github.com/fiatjaf/nostr-wasm?tab=readme-ov-file#is-libsecp256k1-modified

integrity sha512-EbqwksQwz9xDRGfDST86whPBgM65E0OH/pCgqW0GBVzO22bNE+NuIbeTb714+IfSjU3aRk47EUvXIb5bTsenKA==

"@noble/hashes@^1.1.5":
"@noble/hashes@1.3.2", "@noble/hashes@^1.1.5":
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should check what uses "@noble/hashes@^1.1.5" and if we can update it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like @bitcoinerlab/secp256k1@^1.0.5

@rolznz
Copy link
Contributor

rolznz commented Jan 9, 2024

@staab as soon as I navigate to send a DM to someone on coracle using this branch I get a popup:
image

I do not know what I am signing or why this is needed, and it should only popup to sign once I have typed a DM and pressed send, right?

@pavanjoshi914
Copy link
Contributor

image
Pr's still uses nip04 encryption as you don't specify calls in content scripts and instead nip04 prompts are executed can you please try and fix this?

@pavanjoshi914
Copy link
Contributor

image
also there are many codewise fixes we need to do here. for eg this function has 3 arguments passed but function expects only two

@pavanjoshi914
Copy link
Contributor

also we need to make this pr in sync with new nostr signing improvements where we split screens for encrypt and decrypt

@staab
Copy link
Author

staab commented Jan 9, 2024

I'll try to address some of these issues today, as far as

as soon as I navigate to send a DM to someone on coracle using this branch I get a popup

You can ignore that WRT to this PR, that's an event Coracle publishes to track when the user last opened a thread.

@staab
Copy link
Author

staab commented Jan 9, 2024

Ok, pushed an update with the new separated dialogs. The new commit also changes the api to fit what's proposed here. Unfortunately this makes the prompt potentially overwhelming since it might include hundreds of messages. I'm not sure how you want to handle that. Let me know if there's anything else you spot that I can fix! Also, there are a number of type errors and a couple failing tests that appear to be unrelated to this PR.

@rolznz
Copy link
Contributor

rolznz commented Jan 10, 2024

You can ignore that WRT to this PR, that's an event Coracle publishes to track when the user last opened a thread.

@staab it was not a standard sign event request though (with a kind, etc), but a NIP-04 encryption

@staab
Copy link
Author

staab commented Jan 10, 2024

Yep, it encrypts the payload before sending to keep read receipts private.

@staab
Copy link
Author

staab commented Feb 5, 2024

Hey guys, anything I can do to push this forward? Also interested in feedback about the bulk use case.

@rolznz
Copy link
Contributor

rolznz commented Feb 6, 2024

The bulk case makes sense for remote signing and is similar to the new multi_ methods for split payments introduced in NIP-47. For decryption would the user need to really review what they are decrypting (and would they understand it anyway)? maybe we can simplify the dialog there and say "decrypt X messages from <npub>".

For bulk encryption, this would just be for bulk DMs, right (e.g. for advertising?) or is there another common usecase?

@staab
Copy link
Author

staab commented Feb 6, 2024

Yeah, that UX would make sense I think. Use cases would be anything wrapped, so DMs, encrypted chat (NIP 17 draft), key exchange for encrypted groups (NIP 87 draft), anything else requiring encryption. The bulk use case is helpful because a lot of the time these events are requested in the background and many need to be encrypted to get the user up to speed.

@rolznz
Copy link
Contributor

rolznz commented Feb 6, 2024

a lot of the time these events are requested in the background and many need to be encrypted to get the user up to speed

How does the user control this though? I am worried they just end up using the "remember" option and automatically signing everything if they get too many random popups, which in my opinion defeats the point (and you might as well just trust or not trust specific apps).

@pavanjoshi914
Copy link
Contributor

@staab any updates on my feedback? do you need any help?

@staab
Copy link
Author

staab commented Feb 19, 2024

It should all be addressed, please review the PR and let me know if anything's missing

Copy link

socket-security bot commented Feb 20, 2024

👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

View full report↗︎

@staab
Copy link
Author

staab commented Feb 20, 2024

After much debate we have decided to stick to the same interface that nip 04 uses: nostr-protocol/nips#1063

Lots of linting is failing from upstream I believe, let me know if there's anything I can do to improve the PR.

@rolznz
Copy link
Contributor

rolznz commented Feb 21, 2024

@staab can you please update this PR so we can directly push updates to it?

I created a PR here for some fixes: coracle-social#2

@@ -128,6 +128,8 @@ const routes = {
getRelays: nostr.getRelays,
encryptOrPrompt: nostr.encryptOrPrompt,
decryptOrPrompt: nostr.decryptOrPrompt,
nip44EncryptOrPrompt: nostr.nip44EncryptOrPrompt,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we rename the existing methods to be prefixed with nip04?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can do that if you want, just let me know

package.json Show resolved Hide resolved
@pavanjoshi914
Copy link
Contributor

@staab do you know why nip44 encryption is not triggered on coracle on scoial? if i try it on console functionality works great. but i always get nip04 prompt when trying on website. thanks!

@pavanjoshi914
Copy link
Contributor

can you please merge Roland's follow up pr so that tests and functionality fix is present in the pr

@staab
Copy link
Author

staab commented Feb 22, 2024

Got that PR merged.

i always get nip04 prompt when trying on website

04 will still be used for most things, since it depends on new NIPs to invoke nip44. I would suggest sending a DM to yourself. If window.nostr.nip44 is defined, Coracle will ask if you want to send a legacy dm or nip44 one. Click NIP44 to encrypt then reload the page to test decrypt.

Copy link
Contributor

@alexgleason alexgleason left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

API is sorted out in NIPs now. LGTM.

@pavanjoshi914
Copy link
Contributor

@staab can you please sync your fork as with upstream. so that i can push latest changes on your fork

@pavanjoshi914
Copy link
Contributor

pavanjoshi914 commented Mar 11, 2024

@staab i created a new pr for nip44 support and based it off from alby's master branch. i also extracted nip44 into extension itself cause we don't want to introduce nostr2.x now. we do it when alby-js-sdk is upgraded to 2.x. thanks a lot for the contributions and pr. closing this in favour of #3075

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature] Add support for NIP 44
7 participants