hmm... there we have to ask snort. this is a snort message and I have no idea why this would be needed.

what do you mean by reload? what is the issue?

how many concurrent clients do you currently have roughly there? on what resource usage?

It’s about zap providers that need to post to relays here.

no, its not lightning only nostr specific.

seems you have a cash.app link in there not a LNURL / lightning address. I don't know how cash.app works and if they offer that.

centralized whitelists are typically never difficult. it's the decentralized things that are hard, and we want to be decentralized here.

So imo the goal should be that users can use any zap provider and that zap providers do not have to pay any (potentially expensive) relay out there to work.

Limiting this by design leads to centralization which would defeat the purpose.

from my limited past experience websockets have been hard to scale just because connections are persistent. So having 10k users requires hardware resources for 10k users.

so I assumed that typically paid relays would want to limit the amount of open connections and thus limit this to only paying users.

if I am wrong or if this not a problem in foreseeable future then I don't need to further think about it :D

that's my point and question, will we see relays that require user authentication to connect? (because it's the open websocket connections that cost resources)

I mean I am happy to give you the Alby zap pubkey.

but imo that defeats a bit the purpose of the zaps.

So paid relays would require their users to use certain zap providers - and will such likely never allow users to use their own setup to receive the zaps.

If a user runs their own umbrel node for example, they will not be able to use that one to receive sats.

how do you see the connection issue? I guess your relay is easily taken down if somebody just opens a lot of connections. how do you see the authentication issue?

actually, this is not really an option for me.

We build here an open tool ideally on open standards, this would be a flaw that needs to be addressed early and not by centralized whitelists.

You will not be able to add the pubkeys of all potential LNURL-zap providers - we hope to have many of them and not force people by design to use some small whitelisted providers.

spam is always a problem I guess. not sure about the incentive.

do relays have such logic/should they have such exceptions?

and this is still a problem if we have authenticated relays?

that’s not scalable. anyone can run an lnurl server to receive payments. there can not be a central allowlist of providers.

this would require a horrible centralization. (ironically to make something decentralized possible)

true, so it is already an issue, how should that be solved?

and I expect relays to close their public websockets pretty soon.

I would really love to hear more comments on:

@note1sah7u3efewyhylc76p7svdvdpxsth7paesm7j6fjn3g3vcynzkes8y3zst

will relays require user authentication to connect ever in the future? IF so: how should zaps/NIP57 work?

I don't think it is viable that zap tools/providers have to pay all the relays they might need to connect to?

writing there is not the problem afaik because the zap is signed by the sender.

but for the relay unauthenticated connections are a problem those cost resources (websocket connections use a lot of server resources)

and if relays start to require some authentication then NIP57 will fail from my current understanding.

I am very interested how Nostr people see this. Maybe it's a no-problem, or relays just have to deal with it? or LNURL-zap tools/providers have to pay all the relays to be able to connect?

hehe, is that a case? seems the amounts grow quicker than expected :) 🚀

it's actually a very defensive LNURL-pay setting.

what clients support NIP57?

What means ZAP to you?