You don't have a lud16 LN Address in your profile.
Can you add one? Then we can do it.
I'm working on a bot and I'm looking for volunteers to help me test it.
To be eligible, you must have a LN Address (lud16) configured in your nostr profile.
The bot is simple. It "watches" my account and, for every "like" (NIP-25 reaction) I do, it will automatically tip a certain amount of sats to the LN Address of the author of that note.
To volunteer:
- simply reply to this message
- I will "like" your reply, which should trigger my bot to tip you 1000 sats to your LN Address
- I will ask you to confirm if you received them
- check your LN wallet and let me know if you received them or not
What you'll get:
- in addition to the tipped sats, and regardless if the test works, I'll send the first 5 volunteers each 5000 sats
Note: these are not zaps, these are simple standard LN tips, sent from my Umbrel.
So you're asking why are Nostr clients that are replicating twitter, replicating twitter?
I see.
Lets see
- you can already play chess over nostr messages
- you can do coinjoins over nostr
- you have actual e2e encrypted DMs over nostr
- there are multisig setup protocols over nostr
- there are pastebins
- clipboard sharing across devices (copy in one client, paste in another)
- chat rooms with optional moderation
- no algos to shadowban you or whatever
- ability to tip the author of a note directly, with no intermediary taking a cut
- mobile, web, desktop, CLI clients
- an open API with no throttling or registration needed, free of cost
- and more
None of that is available on Twitter.
#[0] congrat for the brilliant design
Ideally, it should fallback on a normal LN tip.
Already working on one, but which sends normal LN tips.
Btw I think sooner or later they will be possible via pure LN (+ send optional proof via nostr).
It's not possible now because when paying, the preimage (proof of payment) is only available in the LN wallet, which is a different app than the nostr client.
As LN SDKs get better, it will be easier to integrate a LN wallet in a nostr app, which will solve this problem at its root.
When sending: it coordinates with the receiver (via nostr messages and via LNURL) to create an invoice for your zap. Then gives the invoice to your LN wallet to pay.
When receiving: it coordinates with the sender to generate and send the invoice, then monitors it. When its paid, it emits a nostr event to confirm the received sats.
To clarify:
They can only be faked as a receiver, and only if you "customize" your receiving zap node. Or if you write some scripts.
For sending, you cannot fake it.
Also, if you're not custom-modifying your receiving zap node, then they're real. All the zaps you receive will be backed by sats.
The reason I point it out though, is because zaps distract from normal LN tips. Which cannot be faked.
Nah, just a minor misunderstanding.
Things will get better, it will just take a while.
That's the right approach, IMO. Glad to see apps giving users more choice.
One thing to keep in mind is that, as per the current zap spec, if a receiver LN addr supports zaps, you cannot (should not?) allow both a plain LN tip and a zap to that recipient. So by offering users that choice in the app settings, you're going against the current spec :)
Which only makes sense, your approach is the sensible thing to do.
Thanks for the thoughtful reply.
Yes, everything that has a social aspect can be gamed, because social signals are shortcuts. Algos take this to the extreme, but human psychology tries to manipulate what it can. Well designed clients can probably keep that in check.
My beef with zaps (in their current iteration) is that they go against the ethos of LN, on multiple levels. It encourages centralization of nodes (DoS risk for receivers), loss of privacy (why document what you send and receive?), just to name a few.
In principle, zaps are very useful. They're are a great vector to drive nostr adoption and innovation.
However the implementation was rushed, thoughtful feedback was ignored, which left weaknesses open. The unintentional cost falls on LN newbies, nostr newbies, and LN decentralization in general, which is why I'm not a big fan of zaps.
Medium/long term though, I'm optimistic. It will soon be possible to have a LN wallet and a nostr client within the same app. This will let the app have direct access to the invoice preimage (e.g. undeniable proof of payment). When that comes, zaps and invoices can be more closely linked and a lot of the current implementation compromises that make zaps a bad design now IMO, will not be ncessary anymore.
For sending: AFAIK you cannot zap from a normal LN wallet (you need a nostr component to initiate the zap)
For receiving: yes, you cannot receive zaps on a normal LN Address (or LNURL endpoint). The LN Address has to be customized with some more fields + has to monitor the pending invoices / zaps. It also needs a nostr component to emit nostr events.
No, both sender and receiver have to support zaps.
A pure LN wallet cannot send or receive zaps.
Two ways:
1. As a receiver, you can emit the nostr event that means "zap received" without having necessarily received LN sats. You can create the invoice, use the preimage, and fake the contents of the zap note.
2. You can also use sockpuppet accounts to zap yourself. You could recycle lets say 100 sats over and over (send zap, receive zap, send sats back silently via LN, repeat). You can thus inflate the amount of zaps recived as high as you want, without having received that actual amount.
If zaps were well designed, the arrival of bad actors would mean little.
But they're not:
- they're easy to fake (encourages low-level bad actors, like scammers and grifters)
- they're easy to DoS: For every incoming zap, the receiver zap node has to keep state and monitor the new invoice until it's settled. This means it's easy for an attacker to overload a zap node by just initiating (but not paying) new zaps. With one simple nostr message, the receiver now has to remember and monitor a new invoice. Multiply x100, x1000 => at some point, the receiver zap node runs out of memory, or is too busy monitoring "pending" zaps, that it cannot accept new ones.
- this brings with it centralization tendencies: Only companies with beefy servers will be able to withstand such attacks. This means simple LN node runners are on the losing side, because they would risk getting their node DoS-ed anytime if they support receiving zaps on their nodes.
State-level CBDC-friendly anti-bitcoin bad actors would in fact encourage zaps because it directly attacts the decentralization of LN nodes.
Wrong, LN does that.
Zaps are layer 3 and are very loosely linked to the LN sats they represent on layer 2.