@pubpay why do you use a kind:1 for a payment request? Evey client that do not understand the `pubpay` tag will display notes without an important piece of information, so they risk appearing meaningless.
Yeah we already have a nip for this kind of thing. I wish more clients would support it. https://github.com/nostr-protocol/nips/blob/master/75.md
same, kind 1 tag overloading without a spec is terrible for interop
The way things are going, we’ll end up with a single kind and a bunch of crap as metadata
lmao, what a mess https://www.youtube.com/watch?v=lKXe3HUG2l4
With current clients, kind 9041 are invisible to 99% of users.
They render in Damus just like your notes do. All other clients need to do is render kind 9041 notes as they would a kind 1 note which is what I think Damus does. Web and Android clients can even do better by rendering it similar to how Heya does it.
I think Amethyst also displays them and Damus and Amethyst are probably the 2 most popular clients
Amethyst uses "zapraiser" tag on a kind 1. Damus doesn't seem to render zap goals in the versions I'm running. Can you share an example? Nostrudel renders it but pushes it out of the notes feed. nostr:note1dfrp7zgt4jl6nwwqskgjzsyxs9t9ks775ukafhjpkenf6y6fph2slxcxf5 https://image.nostr.build/8514edb2b074793f4463c0fa2c16f6036a5e0d2832f7fb901b3fa86313cb54de.png
This is what I mean by renders. It just renders it like a kind 1 note. I think it’s because Apple wouldn’t let them render all the details cause Apple wants a cut. This is exactly how your notes render in Damus.
So the experience is inconsistent regardless. Does't seem like a strong enough reason to stop building on a new standard. We envision a world where more is possible with zaps, and the current tags and standards are just not going to cut it.
Damus can improve the UX for kind 9041 notes using nip-89. If more clients support nip-89, I think it would encourage devs to start building all kinds of microapps.
I will feel better about promoting nip-89 if damus was a signer that protected users from buggy clients
you could hide the options in the more menu. could even make users have to enable nip-89 support in the settings. as an advanced user, it would be awesome to easily open notes in other nostr microapps. the way i do it now is copy the note ID and figure out how to use that to open the note in another app. would be nice to have a link i could click somewhere and have that happen automatically.
Pubpay tags don't conflict with zap-goals. They're complimentary uses cases. We're going to implement zap-goals in https://pubpay.me soon 😎
It's a risk, but clients can adapt or ignore. Moving it to another kind breaks the social proof use case.
The problem is just this: clients cannot ignore only your tagged kinds 1, so you are creating noise in all plain kind:1 apps to take advantage of free visibility, and actually trying to force support. A better approach would be to support kind:9041 and work together with clients devs to support it more extensively. What is that "social proof use case"?
Appreciate the feedback. Social proof use case is pretty self explanatory.