Add support for Nostr Zaps

[mutatrum]

No description provided.

[mutatrum]

Pending blc-org/una#37.

[mutatrum]

Also pending jb55/nostr-js#11, currently the zap request signature is not verified.

[mutatrum]

This is fine to run on LND unless you have gc-canceled-invoices-on-the-fly=true configured.

[sommerfelddev]

Does this work if I run the branch or do I need to wait for the issues you mentioned to get fixed as well?

[mutatrum]

I ran into a problem because of gc-canceled-invoices-on-the-fly=true. If you don't have that set in your LND config, I think it defaults to false and it should be ok to run then, but I have not tested this.

The other issue is that it currently doesn't verify the signature on the zap request.

[ok300]

Each new zap will create a zap request

ligess/nostr.js

Lines 76 to 78 in 216d0e2

	const storePendingZapRequest = (paymentHash, zapRequest, comment) => {
	pendingZapRequests[paymentHash] = {zapRequest: zapRequest, comment: comment}
	}

which the server will remember (i.e. store in RAM) until it either expires or is paid.

What is preventing someone from DDoS-ing via an endless stream of zap requests?

[mutatrum]

Good point, although this is already a DDoS vector for any lightning address handler. I don't see a rate limit option, as one can generate a new pubkey for every request and make valid zap requests.

A simple way of at least preventing OOM would be to define a max number of entries and remove them FIFO.

[seak1234]

Hey, thanks for your work, this is truly amazing! Got it the zaps to work.

To the other rookies out there, these are some steps I had to do additionally to the README.md instructions (other than checking out the specific pull request (ID=9) from github):

1. before running "yarn install" I actually had to install yarn first:
   sudo echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
   sudo apt-get update
   sudo apt-get install yarn

2. I also had to install the nodemon module for npm:
   sudo npm install -g nodemon

3. I personally then also had to change the port of this app. If you have issues you can change it in this file: router.js

Remember to use HEX (!) values for the macaroons and nostr private key.

Again, thank you so much, this is fun!

[ok300]

@mutatrum yes, configuring a "max number of pending zaps" limit can defend against OOM.

But ironically that enables another kind of DoS attack, whereby the attacker floods with enough requests to reach that limit. At that point, nobody else can zap to this receiver.

Is there a way to defend against that?

There's a similar thread in the BTCPay repo: btcpayserver/btcpayserver#4642 (reply in thread)

[mutatrum]

I used npm for the install, and that was a straightforward npm install. Can't remember doing anything else to be honest. I haven't used the yarn installation method.

Adding support for npriv and custom ports can be done, but probably outside the scope on the current PR. Both are trivial to add but I don't want to make this changeset much larger.

[mutatrum]

Is there a way to defend against that?

Not that I can think of, other than rate-limiting the HTTP requests, the rest is trivial to generate. Either way at some point the service will be unavailable during the attack, but that's the nature of open internet I guess.

Thanks for the thread link, added a comment there.

[sommerfelddev]

3. I personally then also had to change the port of this app. If you have issues you can change it in this file: router.js

Looking at the relevant code:

ligess/router.js

Line 75 in d8c7162

process.env.PORT || 3000,

You should be able to change the binding port by passing the environment variable PORT in the .env file
E.g.:

PORT=<some other port other than the default(3000)>

[Sebastix]

Can confirm the zaps are working here, it's running now for two days. Some people had some errors but I think it's due their used clients. Still debugging with them but nothing has come out relevant for this integration of zaps.

[mutatrum]

Some clients are buggy. I just had a zap request without any relays, so it didn't send the zap note.

[sommerfelddev]

It's working for me: note17pfxx953dym0lzlf5flxu6ztdnjgdfqsuk83ghu7f9fmxv0vkmvq0dglaf
Thanks @mutatrum !

[mutatrum]

Should it return an error if the zap request fails any of the verifications? Currently it logs the issue, but still creates the invoice. Problem with this is that it leads to silent failures of zaps not working. Upside is that even with buggy implementations, payment will work, just not the zap.

[mutatrum]

All all pending PRs have been resolved and dependencies have been bumped. I also changed the error handling to return an error on any invalid zap requests. Running this version now, to see if anything weird pops up.