Nostr Web Client

nostr:npub1yfg0d955c2jrj2080ew7pa4xrtj7x7s7umt28wh0zurwmxgpyj9shwv6vg your 9734 is zapping the wrong id, should be using an `a` tag

{

"kind": 9734,

"content": "",

"pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",

"created_at": 1682020029,

"tags": [

[

"relays",

"wss://relay.wavlake.com/"

[

"amount",

"100000"

[

"lnurl",

"https://www.wavlake.com/.well-known/lnurlp/zap"

[

"p",

"7759fb24cec56fc57550754ca8f6d2c60183da2537c8f38108fdf283b20a0e58"

[

"e",

"58e708a590b7d30037e63d5463ad97782ee8e05f6d2f3ae522e0bb7b0e990aed"

]

"id": "d22197c9f3a7efe032744da574bd234204cb329082547424fc97f9f973712f8d",

"sig": "6b2c17a747c00187b90c2401bf4c642c2e36654b8584381b827a984384d0a1b07cdc70adef2248a5199288d615ca0575cc9ec67b4106f437182c2a89054d8f12"

}

that `e` is wrong

Joshr 2y ago

In the wavman app, we set it up to zap the kind 1 event (non-replaceable). So when a user sends a zap to a track, it is sent directly to the kind 1 event and not to a person. The kind 1 event id is set the e tag in the zap.

There is also a kind 32123 (replaceable) metadata event, which is used to house all the track's data. The kind 32123 event is not being zapped by wavman (though we have the endpoint setup to accept zaps to this, albeit this is untested).

I'm interpreting NIP-57 to mean that a zap request MUST use an e tag set to the event id of the kind 1 event being zapped (since its not a person). Should the a tag be included in addition to the e tag?

Reply to this note

Please Login to reply.

Discussion

PABLOF7z 2y ago

oough, yeah, I think that's very un-nostr; what's the point of the kind 1? visibility?

for zapstr I just have a kind that represent the track, having two kinds to represent the same thing feels very weird to me

in zapstr zaps go to the track, but there is no kind 1 so the zaps go to kind 31337 (wink wink to nostr:npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m ) which is the tracks kind I speced out

Joshr 2y ago

Yep exactly, the point of the kind 1 was so that the zaps and comments would also show up in the "standard" nostr clients.

We aren't zapping or commenting on any of the replaceable events, so I don't think the a tag makes sense in this case.

I think we setup things correctly based on our chosen event architecture. The issue is our chosen event architecture may not be ideal! Check out the diagram in this article for more info on the architecture; https://zine.wavlake.com/how-we-built-wavman/

Excited to discuss and explore different options on this 🙂

PABLOF7z 2y ago

also, I tried to zap the kind 32123 but your server is responding with a generic 500 😕, even when I double URI encode

also, all references to nip-33 events should use the "a" reference, otherwise, if the event is replaced, the reference breaks as the ID points to an old version; NIP-57 mentions either tagging via `e` or `a` 😉