would be great if you use kind 9041 (Zap.stream and Heya use this) https://github.com/nostr-protocol/nips/blob/master/75.md
Discussion
Why is a new note type needed? zapraisers can simply be metadata on a note and you would count zaps toward the goal. nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49
I was thinking this would be best for compatibility between clients, you want zaps from as many places as possible.
overloading kind 1 with non specified tags is bad imo but you are right about getting more zaps.
It would probably look more broken on a kind:1 if the client doesn’t know how to render the zapraiser stuff, whereas if it’s a specific kind only clients that can render it would show it and it would be simple to create a client that is specific for these (like Heya)
Amethyst already has zapraisers just a tag in kind 1
This is the way to go, nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z whats the tag?
nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft why would it look weird in kind1? You can do a post like normal, put a description of your fundraiser in the content.
I do a simple ["zapraiser", "
To be fair, I think Zap Goals (NIP-75) can allow people to tell better stories, create a community, etc, and build websites that only support fundraisers.
I think both options should exist. They serve different use cases. A Kind1 fundraiser will never be as refined as a Zap Goal could be.
Probelm with kind1 tags is that kind1s are displayed chronologically, better to quote the zap goal event in a kind 1
Yup, this is better UX ✅ .
Didn't know noStrudel handled these too, pretty sweat.
Why is chronological display an issue here?
The main issue I see with the zapraiser tag is that it’s harder to list and find all the fundraisers.
Downside with quote is that if zap goal type isn’t supported in a kind1 client, the zap would go to the quote and not the zap goal.
what is this Heya thing? link pls