Replying to Avatar Joshr

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?
Avatar
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

Reply to this note

Please Login to reply.

Discussion

Avatar
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 🙂