Event-specific zap markers

[pablof7z]

This small NIP proposes a way to mark events that should be zapped to a different destination than the profile's settings.

UPDATED: merged this proposal into NIP-57 itself.

Formatted: https://github.com/nostr-protocol/nips/blob/e838acef164aedce6bcaca6f3ad7e2f3c45eed50/57.md

[bu5hm4nn]

Since zaps are their own kind on nostr, I think having a shorthand specifically for per-event zaps is preferable in addition to what is proposed in #262 .

[pablof7z]

Since zaps are their own kind on nostr, I think having a shorthand specifically for per-event zaps is preferable in addition to what is proposed in #262 .

what's the benefit of having a different kind for this? it would marginally increase the cost on relays and clients and if a client wanted to know where the zap went to they could pull the referenced note to get the z tag, right?

[fiatjaf]

Can you make it be called "zap" or "nip57" something like that? This doesn't have to be indexed, so using a single-letter puts some unnecessary burden on relays.

Also I think it could be added to NIP-57 instead of being a new NIP.

[bu5hm4nn]

Yes, my statement was meant to be in support of this NIP and I think it makes sense for it to exist in addition to NIP-89 because zaps are already first class citizens on nostr.

[pablof7z]

Can you make it be called "zap" or "nip57" something like that? This doesn't have to be indexed, so using a single-letter puts some unnecessary burden on relays.

Also I think it could be added to NIP-57 instead of being a new NIP.

yeah, I'd prefer to amend, went the new-tiny-nip route because of the drama last time I just edited a nip 😂

I'll rewrite as an amend of NIP-57 and yeah, great call removing the index requirement

[pablof7z]

@fiatjaf ✅

Formatted version: https://github.com/nostr-protocol/nips/blob/e838acef164aedce6bcaca6f3ad7e2f3c45eed50/57.md

[blakejakopovic]

Is it wise to understand how invoice splitting may best work first? Reason being, maybe an event could have multiple z tags with different % or whatever.

It may also be wise to have a client facing indicator to clearly state where the zap is going - which may not be the expected event by author as present.

Thinking out loud.

[pablof7z]

Is it wise to understand how invoice splitting may best work first? Reason being, maybe an event could have multiple z tags with different % or whatever.

It may also be wise to have a client facing indicator to clearly state where the zap is going - which may not be the expected event by author as present.

Thinking out loud.

I think that given that this can be done in a separate layer (e.g. prisms); it should be done there.

splitting payments at this level would increase complexity for clients and worsen the UX significantly

[bu5hm4nn]

2 more places to rename from 'z' to 'zap'

[Egge21M]

I think that given that this can be done in a separate layer (e.g. prisms); it should be done there.

Prisms lack transparency. That's why IMHO client side solutions are the better ones (like the original V4V spec)

[bu5hm4nn]

Prisms lack transparency.

I agree. However that is a much larger topic, and can be ammended later for both profile and per-event zaps. If we wait until we have solved that problem, we are missing out on some low hanging fruit improvements we can already do now.

[pablof7z]

I think that given that this can be done in a separate layer (e.g. prisms); it should be done there.

Prisms lack transparency. That's why IMHO client side solutions are the better ones (like the original V4V spec)

I agree with @bu5hm4nn that this is scope creep.

[fiatjaf]

Is any client implementing this?

[blakejakopovic]

I think that given that this can be done in a separate layer (e.g. prisms); it should be done there.

Prisms lack transparency. That's why IMHO client side solutions are the better ones (like the original V4V spec)

I agree with @bu5hm4nn that this is scope creep.

Whenever something is designed as a supporting the singular case only, and it's likely desirable in future for the none, one or many case, I just like to consider is this the right architectural approach, or should it be more flexible.

I still think some kind of client UX note around making it obvious where the funds are destined is important. Sure it's a zap and likely a micro payment, however whenever money is being sent it's critical we make it as clear as possible where it's going.

If you guys have considered that, then all good.

[pablof7z]

I think that given that this can be done in a separate layer (e.g. prisms); it should be done there.

Prisms lack transparency. That's why IMHO client side solutions are the better ones (like the original V4V spec)

I agree with @bu5hm4nn that this is scope creep.

Whenever something is designed as a supporting the singular case only, and it's likely desirable in future for the none, one or many case, I just like to consider is this the right architectural approach, or should it be more flexible.

I still think some kind of client UX note around making it obvious where the funds are destined is important. Sure it's a zap and likely a micro payment, however whenever money is being sent it's critical we make it as clear as possible where it's going.

If you guys have considered that, then all good.

you don't know where any of the money you are sending goes to; you pay for groceries and don't know how it'll be split, a you donate to HRF and don't know what happens next -- I don't think this is any different

and regardless, if this were a problem (I disagree it is), then profile-based zaps have the exact same issue and need to be fixed at that level as well; this PR just introduces a way to do the exact same thing a profile-based zap is doing

[pablof7z]

Is any client implementing this?

not yet, it hadn't been proposed yet, but once we move towards more than tipping for funny notes, being able to explicitly specify different destinations of zaps will be very useful (imagine zapping a song you liked that was created by three collaborating authors)

[bu5hm4nn]

Honestly this should have been in the original NIP-57 to begin with. Consider it a patch.

[KoalaSat]

Is there a way to associate this zap with receiver's pubkey?

I'm thinking on a case where the LN address and nip05 are located in different services.

[bu5hm4nn]

Is there a way to associate this zap with receiver's pubkey?

I'm thinking on a case where the LN address and nip05 are located in different services.

This is already not a problem with NIP-57. I have separate lnurl and nip05 on my profile, no problem.

Also important to note: including the addition proposed in this PR in clients can be as simple as 2-3 lines, where they just pull the lnurl from the event as opposed to from the profile if present.

[Egge21M]

I fear that this approach could lead to problems with stale lnurl and addresses.

Imagine a famous blog post that will be read for several years. While a lud06 inside a kind-0 could be updated whenever the author changes their Lightning address, an event zap tag would be immutable, right?

[dergigi]

Prisms lack transparency.

Agree, but as @bu5hm4nn said that's a bigger can of worms.

Event-specific zap markers are still very useful for forwarding zaps to a single user, e.g. when posting a "stolen" meme, sharing an article of an author that is on nostr, forwarding funds to charity, etc. It's a well established practice on StackerNews already.

Is there a way to associate this zap with receiver's pubkey?

I'd be in favor of that, as briefly mentioned in the prism article.

[pablof7z]

Yeah, the zap receiver is still tagged, along with the event, on the zap event; that doesn’t changeOn 27 Mar 2023, at 12:24 AM, Gigi ***@***.***> wrote: Prisms lack transparency. Agree, but as @bu5hm4nn said that's a bigger can of worms. Event-specific zap markers are still very useful for forwarding zaps to a single user, e.g. when posting a "stolen" meme, sharing an article of an author that is on nostr, forwarding funds to charity, etc. It's a well established practice on StackerNews already. Is there a way to associate this zap with receiver's pubkey? I'd be in favor of that, as briefly mentioned in the prism article. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[fiatjaf]

I like this, the entire NIP-57 should transition to using this scheme instead.

[Egge21M]

I can definitely see this becoming very useful for forwarding Zaps, however I have the feeling the downside is enormous.

People change their Lightning Address from time to time, move from a provider to another or go non-custodial. If we introduce event specific zap-tags and it becomes "the standard", we risk introducing a barrier for changing your lnurl, because you will not receive "old" tips no more. Also non-expert users might not be aware of this.

So this should only used sparingly and only if the situation requires it (for example as @dergigi mentioned, a repost of non-original content).

PS: Maybe we could add some lines like "clients SHOULD NOT add a zap-tag by default, but only if the user explicitly sets one"?

[fiatjaf]

Can we get rid of the bech32 dependency and just post the URL directly?

[Semisol]

The zap tag should point to a public key. And that pubkey should be used for the p tag, and the metadata used to determine the zap destination.

This allows for changing the destination address if required, and if you just want to forward it to someone, it will also update with their own LN address.

[pablof7z]

This is an interesting option. How about we make that a PR for version 2 of this proposal?
It adds more complexity.

I think most clients are planning or some already have wallet connections so making multiple payments isn't an issue imo.

my main problem with bringing splits right into the event is that it means clients must implement their own wallet, which is not a simple feature. A client that prompts the user n times to confirm a single zap simply cannot compete.
Fewer clients = more centralization
Prisms are a non-ideal solution, but I do think moving that complexity away from clients, and keeping zaps atomic from a client perspective is preferable.

The same argument could be made against NIP-57 as a whole, clients without wallets have a worse experience than those that do.

not really, I use snort with getalby and it works perfect, I zap, I get a popup, I pay

with a 3-way split I would see three popups

with damus, I zap, I'm taken to Zeus, I confirm, back to damus

3-way split? 6 times going back and forth between apps 😕

[v0l]

not really, I use snort with getalby and it works perfect, I zap, I get a popup, I pay

with a 3-way split I would see three popups

with damus, I zap, I'm taken to Zeus, I confirm, back to damus

3-way split? 6 times going back and forth between apps 😕

You chose not to set a quota for alby and press confirm every time, that's on you 🤣

But this is a wallet in the client essentially, so its not comparable to Damus where you actually HAVE to go to another app to pay a single invoice.

But whatever if you want the simple case then don't let me get in the way of that. Im just giving my 2 sats for a better UX for snort users (or amethyst since they have wallet connect).

[mikedilger]

Gossip client will never implement a wallet, it will (is in the process of) implementing zaps by showing a QR code of an invoice. Whatever this PR does, it must not break gossip's ability to do that.

[pablof7z]

lol,

not really, I use snort with getalby and it works perfect, I zap, I get a popup, I pay
with a 3-way split I would see three popups
with damus, I zap, I'm taken to Zeus, I confirm, back to damus
3-way split? 6 times going back and forth between apps 😕

You chose not to set a quota for alby and press confirm every time, that's on you 🤣

lol, it's not on me, it's on @Semisol! (I think it was @Semisol who did the lnurl-return-3x-the-original-zap-amount)

ultimately, there's a lot of complexity there that can trick the client+wallet

whereas if you want to zap 10k sats to listen to a song, you see a single invoice for 10k, you confirm and that's it.

Also, imagine if you want to zap 100k sats for a song, you zap the first person in the split 50k, then run out of funds on the wallet, person #2 is fucked (I know prisms are not perfect here either, but at least the 100k from the sender are there) -- person #1 is now a cantillionaire 😂

But this is a wallet in the client essentially, so its not comparable to Damus where you actually HAVE to go to another app to pay a single invoice.

But whatever if you want the simple case then don't let me get in the way of that. Im just giving my 2 sats for a better UX for snort users (or amethyst since they have wallet connect).

Thanks, @v0l -- I think we're all working towards the same goal 😀

[pablof7z]

Gossip client will never implement a wallet, it will (is in the process of) implementing zaps by showing a QR code of an invoice. Whatever this PR does, it must not break gossip's ability to do that.

thanks @mikedilger -- this is PRECISELY my point

splitting payments in-protocol is a massive ask on clients that centralizes nostr

[blastshielddown]

keeping zaps atomic from a client perspective is preferable

My 2 sats: this makes the most sense to me from a client standpoint. It's already unclear/non-standard how v4v/podcasting 2.0 clients are supposed to handle partial failures when it comes to split keysend payments and I have heard anecdotally that it has created problems for podcasters. This feels like it would create the same issue. Simpler is better IMO.

---

Regarding zapping music (or any content in general under this proposal for that matter): We run a Lightning-based music site as well (Wavlake) and have been thinking a lot about how music could fit on Nostr and incorporate zaps natively. For now, we've taken the approach of creating an embeddable player for Nostr clients that has its own zap button users can set an amount for and pay with their wallet. I think the PR @v0l just shared is a good example of separating the concerns of allowing a user to attribute zaps for an event to another user vs. having an event define both a piece of content and the creator's payment address. It makes it easy for anyone to share media from anywhere and attribute the creator if desired.

That said, I think defining a piece of content in an event and attributing that event to a creator is a different matter. The question I have is whether it makes sense to intertwine content itself so closely to an event, esp if the content's hosting situation changes or, as mentioned above, the creator changes their address for receiving payments (I realize events are replaceable but the lack of guarantees on this makes me think events are close to immutable). @pablof7z Would be happy to dig in more on this question in another discussion if you like.

[bu5hm4nn]

Hey everyone, it's not an option to just let PR's starve. Either merge it or constructively engage with arguments why it should not be merged.

[Egge21M]

With Wallet Connect coming up, there really is no excuse anymore to not love complexity to the client side. Clients can implement native wallets or use one of the many ways to control one (WebLN, Wallet Connect, REST).

I personally think we should move forward with @v0l suggestion, of an array that includes pubkeys and splits.

[bu5hm4nn]

Why can't we have both?
This PR is so humble, it doesn't even want to be a new NIP. It is the first step of many toward a value-4-value content market (currently @pablof7z is working on a music distribution concept).
He purposely kept it very simple, in the spirit of nostr.
Why not create a new PR that specifies how to do splits?

[Egge21M]

Why can't we have both?

This PR is so humble, it doesn't even want to be a new NIP. It is the first step of many toward a value-4-value content market (currently @pablof7z is working on a music distribution concept).

He purposely kept it very simple, in the spirit of nostr.

Why not create a new PR that specifies how to do splits?

Works for me. This PR still should be modified to use pubkeys instead of static lud06/lud16.

[bu5hm4nn]

Except that pubkeys won't solve the use case. The implementation @pablof7z is working on will use replaceable events and a special server will create unique lnurl's for each note. Nobody is saying "zap" tags need to be the standard on kind:1 events. Maybe they shouldn't be used for kind:1 events but only for replaceable events. But I would leave that up to the app designer.
I also don't see any benefit of entering pubkeys over what we already have with profile zapping. Just so I can enter someone else's profile as the zap target?

[Egge21M]

Except that pubkeys won't solve the use case. The implementation @pablof7z is working on will use replaceable events and a special server will create unique lnurl's for each note. Nobody is saying "zap" tags need to be the standard on kind:1 events. Maybe they shouldn't be used for kind:1 events but only for replaceable events. But I would leave that up to the app designer.

I also don't see any benefit of entering pubkeys over what we already have with profile zapping. Just so I can enter someone else's profile as the zap target?

"Forwarding" zaps is a huge usecase in itself I believe and as many have pointed out a zap-tag lays the groundwork for payment splitting.

I don't think the spec should adjust to fit single and edge use cases. That put aside, I wouldn't mind having different types for the zap-tag that could either be static or dynamic, as long as using a dynamic one is preferred / encouraged.

[fiatjaf]

Someone please fix conflicts.

[blastshielddown]

I wouldn't mind having different types for the zap-tag that could either be static or dynamic, as long as using a dynamic one is preferred / encouraged.

I like pubkeys over the long term because they're native to Nostr. While enabling the option of either would be convenient for now, lightning addresses are just one way that static payments could work for Nostr clients in the future. Seems unnecessary to bake any non-native option into the spec.

[Egge21M]

I like pubkeys over the long term because they're native to Nostr. While enabling the option of either would be convenient for now, lightning addresses are just one way that static payments could work for Nostr clients in the future. Seems unnecessary to bake any non-native option into the spec.

Absolutely aligned here. Just to clarify: "I wouldn't mind" = "If you really want to do this, I am okay with it" in this case. Pubkeys > static payment options.

[fiatjaf]

Merging this because it's a simple addition to the spec as it already exists, for the good or bad. I do think other specs, similar to NIP-57 but different, hopefully with different use cases, but also generic, could be created. If someone does that, it would be nice to make something more nostric. Comments on this issue could serve as inspiration for such a spec.

[bu5hm4nn]

Imagine the UX when a client has to try to find the profile on relays after a user presses the zap button. All info needs to be present for a good UX.

[Egge21M]

Imagine the UX when a client has to try to find the profile on relays after a user presses the zap button. All info needs to be present for a good UX.

That events are relational is the nature of nostr and Clients can implement it in a way that UX does not suffer... if you travel further down that path you would need to start inlining user metadata into all events...

[Egge21M]

Merging this because it's a simple addition to the spec as it already exists, for the good or bad. I do think other specs, similar to NIP-57 but different, hopefully with different use cases, but also generic, could be created. If someone does that, it would be nice to make something more nostric. Comments on this issue could serve as inspiration for such a spec.

Wording on this NIP needs to be updated to avoid that clients default to this without thinking about the aftermath. IMHO static tip targets need to be used with care and this NIP should point that out. I will open a PR later today.

[jb55]

confused why this was merged without the pubkey option... I'm not sure damus will implement this as is.

[pablof7z]

confused why this was merged without the pubkey option... I'm not sure damus will implement this as is.

leaving the pubkey option for a subsequent PR

[v0l]

Planning to implement the pubkey version soon, next week

[fiatjaf]

Please agree on a single version.