What means NIP57 to you?

imo a problem is that a websocket connection will be established and require resources if the authentication is done on the note/pubkey signature layer as it is currently done. Unauthenticated websocket endpoints are harder to scale and are easier to DoS.

but my experience scaling websocket connections is limited - hence my question :)

lightning invoices sadly will not work. Lightning invoices can only be paid once.

Phoenix is an amazing wallet, but it requires you to be online/have the app open to receive payments. So it works perfectly for p2p transactions but sadly not in the case for Nostr.

still wondering about this:

IF Nostr 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?

requiring some authentication makes sense to protect against resource expensive connections - against DOS. is this correct?

https://www.bitrefill.com/

and https://nostr.directory/ obviously :)

how do I get access?

#[0]

Looking for a list who to follow, check out the replies on this one: https://twitter.com/getAlby/status/1625966381832306700

With Tailscale on your computer, yes. then you can also simply connect the Alby extension to your node in Tailscale.

for the @getalby.com lightning address this does not work.

on iOS there is currently the quite nice Orion browser (though it still has some bugs) and support for Safari is coming.

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)

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

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

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)

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.

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

#[0]

If you ask a provider why it does not yet support NIP57, imho you also should ask why it even has to implement something to support that. Interoperable standards mean nothing usage specific needs to be implemented.

I.e. if I want to build a web client I also don't have to tell browsers to implement certain specific tools. I build on web standards that can be used in any way.

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?