It's in the interest of the users receiving zaps to get their zap provider activated on the relays they publish to.
Discussion
is this practical? How will zap provider know which relays their users publish to?
Or we need a protocol to do this automatically (e.g. though LSAT authentication) but automating the payments completely to those relays (when a new relay is used) opens up an attack vector.
Well, when you're sending a zap you want it to be seen, so your client must choose wisely where to publish that. I think you'll likely want to publish to places the readers of the note you're zapping are likely to read zaps from.
yes, but the LNURL-ZAP provider needs to publish it, and I was wondering about relay authentication for that.
IF relays authenticate users before allowing websocket connections then the zap provider needs to also be authenticated there. (which is the question how zap providers will do that - How will a zap-provider publish a zap to a client defined relay that requires authentication?
(nothing that is currently the case as all paid relays only authenticate signatures afaik. but my assumption was that websocket connections are the expensive ones so relays might want to only allow authenticated connections in the future)
I believe the LNURL zap NIP has a design problem at its root, at least how I read it. The LNURL provider needs to send proof of the zap to every client that reads the post, independent of any relay. This proof-of-zap should be saved on the relay by the zapper so other readers don't need to go out to the LNURL provider for each post. To do this adds an enormous load on the clients and on the zap provider and would discourage LNURL providers, particularly small ones, from participating. Who wants their RPi DDOSd each time your receive a zap?