and a follow up question to this @note1cv2sz8cjv7vx6yragzvlv7n8fshjfg9ynnpgh3nez0vvf9tawtjspgenly

IF relays will require user authentication to connect and post, then it will not be possible to publish zaps to those nodes as lnurl-zap providers are not authenticated. (unless the lnurl-zap providers would pay for all of them)

is this correct?

Reply to this note

Please Login to reply.

Discussion

Indeed, only works for free public relay?

I am trying to understand this currently to be able to plan implementation.

there will always be public relays for this purpose..! so iterate to users relay from 9734 and try publishing it in all of them..!

I also think big zap providers should want to host their own zaps (in addition to whatever they were told to publish to) and clients will know that and fetch zaps directly from them.

How will clients know that they should load the zap notes from the zap provider?

I thought the idea was that those should be published to those relays that also have the note (the note that was paid)

I don't know, I don't think there is a consensus. If you think that you can publish the zaps to the relays that have the note.

I think that will work in some cases, but not in others. For example, where do you read replies from? You can be following some profile on an open relay full of spam, but you don't care since you're only fetching notes from that person you're following -- but you don't want to fetch replies to that note from that same relay, since they will be all spam replies, you want to fetch replies only from safer relays, paid or with other antispam techniques built in.

Same could apply to zaps -- although zaps already have an antispam mechanism. If zaps had an indexed "m" tag (for "msatoshi") that could allow clients to filter out very small zaps and that would be better.

Seems the solution, #[7] also implement it like that based on https://github.com/jb55/cln-nostr-zapper/blob/master/index.js

from how I understand this code this only works if connections to the relays are open an unauthenticated.

Yeah, I think so, only based on tagged relay and only works for tagged public relay. Devs need some workaround to add "popular public relay" probably such that zap response can be more visible 😅

i am just taking zap as OPTIONAL thing - feature for pother purpose - tips can be send without zaps - let see how it EVOLVES

yes, exactly. we already have this and all lightning addresses can be used.

It's in the interest of the users receiving zaps to get their zap provider activated on the relays they publish to.

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?