don't check zap request pubkey

[JssDWt]

The pubkey from the lnurl response is actually not in the zap request:

Example request:

{"kind":9734,"created_at":1764153982,"content":"Zap!","tags":[["p","3ddc1b50190c42b9ec5d5814a0adc32ed77f6303b729a1b66b704d237ec920d4"],["amount","21000"],["relays","wss://nos.lol/","wss://offchain.pub/","wss://relay.nostr.band/","wss://relay.nostr.nu/","wss://relay.damus.io/","wss://relay.nostr.band/","wss://relay.primal.net/","wss://relay.damus.io/","wss://relay.nostr.band/","wss://relay.primal.net/","wss://nos.lol/"]],"pubkey":"827f4652720ac099887de85e7ce4c92ebb2bee09859522263783a2af262c63d0","id":"449db6a037adacf854bccb4e3fe6942f4678cc888992ece2b95f9b238132be2a","sig":"1272a85779334d75f78336044f89174db3765b8039280fb352eb378dc081a7949e361b23866a7996d5389a236d7768f83fcd4aa6e0c46a71db09b0e2098b305e"}

Our nostr pubkey: 0af73fd4383afc8f3001b1c650aac01f111fec7bed027fb415181ba66cdec53e

So just create a zap receipt on the client side when it's not there yet.

[dangeross]

Are we going to run into issues if we send a zap receipt event signed by the wrong nostr pubkey (the one in the LNURL info response)?

[JssDWt]

Are we going to run into issues if we send a zap receipt event signed by the wrong nostr pubkey (the one in the LNURL info response)?

@dangeross I'm not sure. I guess that depends on the client, I haven't gone too deep into that. But you're right it's not very nice.

What I could do is persist the nostr pubkey with the payment hash on the server side. Then the server side can handle only invoices where the nostr pubkey is its own.

The client will sync the nostr pubkey along with the other metadata. It will decide to publish the event if the pubkey is its own as well.

How does that sound?

[dangeross]

What I could do is persist the nostr pubkey with the payment hash on the server side. Then the server side can handle only invoices where the nostr pubkey is its own.

The client will sync the nostr pubkey along with the other metadata. It will decide to publish the event if the pubkey is its own as well.

Sounds like it could work. I was wondering if it's enough to persist the nostr pubkey with the payment hash, then the server validates the persisted pubkey for the zap is not it's own before going ahead and publishing the event. I guess you don't even have to persist the pubkey, only a bool if it's the server pubkey or not

[JssDWt]

Sounds like it could work. I was wondering if it's enough to persist the nostr pubkey with the payment hash, then the server validates the persisted pubkey for the zap is not it's own before going ahead and publishing the event. I guess you don't even have to persist the pubkey, only a bool if it's the server pubkey or not

Yes sounds like that would work. I'll cook that up tomorrow.

[dangeross]

If the server creates/signs the zap receipt instead of accepting the client one, does the client's zap receipt get updated? I'm assuming at the next sync it pulls it from the server, but just checking

[JssDWt]

That is a good point. I decided to return the used zap receipt from the server, and use that for storage in the client.

[danielgranhao]

LGTM. Just some nits

[dangeross]

LGTM