Zap splits implementations

[alexgleason]

Which clients out there properly implement zap splits?

Are there any known clients that implement zaps and do not implement zap splits?

[staab]

Coracle does not implement zap splits. I'm going to have to sooner or later, but I started at one point and the spec is so bad (and required a lot of updates to my assumptions) that I gave up.

[alexgleason]

What's bad about it, the fact you have to resolve the pubkeys first?

[staab]

It was partly due to Wavlake's non-standard zap tag implementation, which made it really annoying to figure out what format the splits should take. But my main complaint about the actual spec is that weight is optional, and there are events out there with no weight, all tags weighted, or only some tags weighted, which is all spec compliant but unnecessarily complicated. I think this ambiguity has actually been improved in the spec since I last read it:

"If weights are only partially present, receivers without a weight should not be zapped (weight = 0)."

But still, what's the point of a zap tag with no weight? It's a no-op. It also creates a situation where if you're editing an event with un-weighted zap tags, adding weighted zap tags removes the zap split for the original p tag which had been receiving 100% of the zap, and now gets 0%, just because the client didn't add a weight to it. It's just all so weird and messy to get all the edge cases.

[vitorpamplona]

Even if weight was required, you would still see splits without any weight out there. The spec can't enforce it. So, the wording was just to make everyone aware that no weight is equal to 0 share. Those who are creating such events should fix their clients.

[jb55]

still blown away that clients wishing to zap it SHOULD calculate the lnurl pay request based on the tags value instead of the event author's profile field is even in the spec, considering how insecure it is. Damus would never implement it this way. This should say MUST or SHOULD calculate from the profile.

Otherwise, there's no way to build a secure UI for this. I would want to be able to verify and show that the splits went to the intended place.

[vitorpamplona]

there's no way to build a secure UI for this

Can you elaborate? I collect all the zap tags, load the pubkey's kind-0 for each, get the ln address, and display the % each will receive before the user clicks on the zap button. Wouldn't that work? You can also do it in a confirmation screen after the user clicks the zap button.

[jb55]

I see now, I think I misread. I thought this was saying load the lnurl pay request in the event tags instead of the pubkey.

I remember an earlier version of this spec which used lnurls instead of pubkeys which is why I never implemented this. It looks like that is not the case anymore?

[jb55]

maybe this could be worded:

clients wishing to zap SHOULD calculate the lnurls from the profiles of the zap tag pubkeys instead of the pubkey of the note.

[vitorpamplona]

Yep, that was the initial zap forwarding (no splits). The new version just uses the pubkey directly. Then I agree: that version was really bad.

[v0l]

Snort implements zap splits, i ended up refactoring all zap flows to get it to work.

Ended up with this zapper class which takes a list of targets: https://git.v0l.io/Kieran/snort/src/commit/5fc844b911d91fd09262bc2ade2b1012feeb09c5/packages/app/src/Utils/Zapper.ts#L53

Its pretty hard to do this well though, in my code if some payments fail we just skip them, ideally you could retry though

[vitorpamplona]

I agree. The hardest part is dealing with the user's expectation when one of them fails.