Then only send NOTIFY for accounts that have paid before, which is a much smaller set. This is not supposed to be for new users anyway which will need more handholding into what they are buying.

I am not saying that it needs no changes. I am happy to code whatever is needed. But this "ohh this is too hard for my server to handle" excuse of sounds just lazy.

Reply to this note

Please Login to reply.

Discussion

So, the reason I would want callbacks, is that I can generate all these lnurls per-pubkey given that the client performs the auth. I may still have to generate just as many (or i may be able to re-use them). But then, my backend does not know immediately that it was paid, the polling cycle has to check all the invoices and the less quick it is, the more likely the user will continue to receive the notify (and be blocked from access). This could be on the order of minutes. With a callback, the payment check can happen and we don't need to rely on polling. (polling bad, callbacks good, that's compsci)

And I do not want to deploy an inefficient solution just because someone thinks it is good enough. It can handle it, and I have done it. But I don’t want to waste resources for no reason if I can avoid it.

Up to you man.. I made this thing just for you guys to get paid because I know how hard it is to collect and how much friction exist in your systems today. The goal was to make something so simple that any client can implement in one night and users just need to 1-click pay.

LNURL already fixes this problem. Arguably NOTICE is terrible for user experience as it provides no feedback to the relay operator and basically stops the entire application flow for a payment prompt.

Cool beans. How many clients implement this LNURL solution?