search

nostr-protocol / nips

Nostr Implementation Possibilities
2.39k stars 582 forks source link

Create fifth parameter in zap tag #1416

Open patrickReiis opened 3 months ago

patrickReiis commented 3 months ago

A normal zap happens when the lightning address is got from the kind 0 of the recipient being zapped. A zap split takes into account the lightning addresses of the kind 0s of the pubkeys specified in the zap tags instead of the recipient's pubkey.

If I am zapping someone directly, I am sure of what I'm doing. If I am zapping someone directly and 5% of the total amount goes to a random pubkey, I may get skeptical and may refuse paying it.

Therefore, one way to prevent such cases is to explain to the user who are the extra pubkeys. I don't think using the about field from the kind 0 is a good idea because it's more intended for general cases, the message in the zap tag is more straightforward, example: "Designer of Snort", "Creator of Amethyst", "Relay X", etc...

I don't think this is a breaking change because it adds a parameter to the end of the array. This feature seem to be done separately by some clients, but if done separately then no interoperability is achieved.

staab commented 3 months ago

I think this makes sense. Nitpick in the PR, I would leave the blank ones off the tags, to indicate that they're optional. Other than that, we just need 2+ clients to implement in order to merge.

patrickReiis commented 3 months ago

Nitpick in the PR, I would leave the blank ones off the tags, to indicate that they're optional

Ok, I'll do it once 2+ clients implement it, then I'll come back here

patrickReiis commented 2 months ago

Ditto implements this: https://gitlab.com/soapbox-pub/ditto/-/merge_requests/468