That's one of the main use cases of Oak Node (app on Umbrel).
You can setup reccuring "push payments", with a set amount, for a chosen LN Address. Can change frequency, or stop them at any time.
Won't this create echo chambers tho?
Which is fine, people can use other clients, but still worth considering if this is a desired outcome.
Typically happens when you're changing clients, or changing your relay list in fundamental ways.
Solution 1: Use clients that have local follows, like Gossip.
Solution 2: Avoid changing clients. If you find one you like, stick with it. If you want to try new ones, try them with a different key.
Many clients don't work well with others, which leads to some accidentally over-riding what you've done in the other. Then they publish this to the relays, and your other clients assume this is your new data (new profile, new follow list, new block list, etc).
Zaps (public display of amt sent/received) are dangerous and a dream-come-true for scammers. Because wash-zaps are easy, 3rd party cannot detect fake zaps from real.
Likes are superficial, but nostr is an open protocol and they can mean anything.
For example, a like can trigger a Shadowy LN Tip: https://oak-node.net/doc/trunk/doc/ons/ons-3.md
In this case, they mean real hard sats, visible only be sender and receiver. No "wash-sending" possible. No algo to influence. No vanity games.
Or even _because_ of the current excitement.
Many are self-invested in zaps as a concept, which prevents from from seeing simpler, more private alternatives.
Honest sender, honest receiver: zaps cannot be faked
Honest sender, dishonest receiver: could, but validation on sender side should prevent it
Dishonest sender, honest receiver: cannot be faked
Dishonest sender, dishonest receiver (working together): can be faked, no LN tx even has to take place
Dishonest sender (sockpuppet of receiver), dishonest receiver: can be faked, no LN tx even has to take place
---
Btw, a 3rd party (any nostr account who is neither payer nor receiver in this zap) cannot tell if the zap was authentic or faked.
Why not update the NIP? Its still marked as draft, so can be changed where necessary.
NIP-05 was written in the very beginning.
The use of bech32 keys for better and safer UX was added only later: https://github.com/nostr-protocol/nips/blob/master/19.md
Looks good.
You may want to prioritize npubs over hex though, maybe get rid of hex entirely.
Bad idea, but this won't stop people from trying it.
Yes. Finishing it up and preparing a PoC with a test paid relay soon.
Check out Shadowy LN Tips
Unless clicking the like button results in sending sats privately.
Man, I spent almost a week trying to do both, and still there were edge cases from weird clients. Gave up.
There are 2 ways to do replies, the older and the newer way, see NIP-10: https://github.com/nostr-protocol/nips/blob/master/10.md
Some major clients still support the old way (Damus AFAIK), most newer clients go with NIP-10.
To be fully compatible with all, you'd have to implement both ways.
