I think our little raspberry pi running Umbrel wouldn't be able to handle let's say 5,000 zaps per day for over a year without blowing up.
If we did 1 sat zaps to replace "likes" I think both nodes and relays would explode.
Discussion
Definitely and interesting thought experiment.
On the nostr side I think each zap-like would produce 2 notes (kind 9734,9735 per NIP-57). Today likes (reactions) are a single note (kind 7, NIP-25). So if I’m interpreting the NIPs correctly we’d see double the notes if we moved to zap-likes as specified today.
On the lightning side I’d be surprised if there was much issue. We should be able to scale an invoice service backed by a database of small transactions to well over 5k ops/day.
What do you think?
Once your node's database is full of that many ln invoices, especially on cheap hardware, it will get so slow to query over time.
I also think centralized services like WoS will likely put in minimums soon.
Right now if your node is on AWS and you're using a serverless DB, 1 sat does not cover the read and write cost of inserting that row in the dB.
Our zapping on nostr will help LN solutions and centralized services to get better. They gonna have to learn fast…
Receiving zaps on your umbrel is a bad idea.
You expose your entire node to DoS attacks.
To initiate a zap, all it takes is one request. The node has to then create an invoice and monitor it until it's paid.
Its trivial to create a script that creates endless "zap requests" for one receiver. With every new request, there's one more invoice to monitor. Sooner or later, the node is 100% busy checking pending zaps and cannot do anything else anymore.
This is different than normal LNURL, because there, after the invoice is created, its not monitored.
LNURL generates a fresh ln invoice for each get request too, I don't think there is any difference in how it's monitored. I have an LNURL implementation I coded from scratch, it's just an endpoint where you serve a normal lightning invoice...
