At least ~32KB and 1 CPU-ms, if you account for the fact that there will be garbage collection jobs, database overhead and more.
Now there are thousands of connections to your relay and you serve out invoices to each user because no client tells you if they are connecting for what purpose, many of them don’t even support it (but you don’t know that) and some are straight up bots wasting your resources
And resources are way more expensive on LN nodes since they have to be secured well and require higher redundancy and stability than the average server.
Ohh, why don't you cache the invoices? If you already have one for a non-paying user, you can just send the same one back, no? If you have ~1000s of users hiting you, you only need to keep and track ~1000s open invoices per month. That doesn't sound hard: 32MB and 1 second to create for the entire month?
I don't know... nostr.wine and others seemed to have solved this issue just fine.
This still has not addressed the DoS vector, and just because someone has solved it inefficiently on top of a garbage solution doesn’t mean that the solution is good and needs no changes whatsoever.
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.
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.
