Since we're talking Bitcoin's on-chain fees, now's a good time to start using Lightning even more than you currently are using it now. Here's a list of Lightning wallets that fully integrate with Nostr Zaps.
NIP-57 Zaps compatible wallets:
strike.army
vida.page
stacker.news
Bitcoin Jungle
ln.tips (LightningTipBot)
Geyser
Bitcoin Beach
Current (Client+Wallet)
Wallet of Satoshi
Zebedee
Alby
AnonSats
Self Custody:
BTCPay Server
nostdress
Fees = high
What does NIP-57 do? Make it so you don’t have to leave Nostr to zap? Usually I have to press zap, then approve the transaction in my wallet (Muun)
NIP-57 is just Nostr aware Lightning tips so the tips can be calculated on profiles and notes. It allows us to see a notes true value.
Ligess as well on the non custodial side.
Oh I wasn't aware they added NIP-57 support. I'll add it for next time around. Thanks.
i know there are a couple people on here that have gotten it successfully to work despite the weird error i'm having. My current lnurl is via ligess.
it was a fork that implemented nip-57 it but it got merged into the main branch relatively recently
ligess
The Lightning Standard
Maybe nostr:npub1y24gz5gwucl79vtv4ctwpysl0r5m4xyzu2rgulnr44ks3t5mt92q4nz2ad or nostr:npub1a3xjg8pngvgm8gcygvlwx3ptu2wsaz88asvmshkl9waznwf4vh3qqrx0r7 can confirm but BTCPayServer deserves another category: With LNbank and nostr plugin, one BTCPayServer can serve many people. "Uncle Jim" model. We need to give more use to existing BTCPayServers and their lightning nodes. Sadly there is an economy of scale, making bigger nodes much more efficient than the self-custodial everyone for themselves.
Always hard to compete with centralized solutions that offer smooth experience as a dedicated team is there to manage the heavy lifting...
But we do our best to still offer the best anyway, and we have some insane things planned to solve these issues once and for all, but resources are tight and we're a small team that live on ramen. 😂
May I ask what client you are using? The JSON marked this as a reply to OP while also mentioning my post which I assume you hit "reply" to. This looks like a bug in your client.
Plebstr though I'm switching between amethyst and it constantly so not sure which one I used then 😅
Did it again, can see the different in amtheyst nostr:npub1plstrz6dhu8q4fq0e4rjpxe2fxe5x87y2w6xpm70gh9qh5tt66kqkgkx8j
Astral:
https://void.cat/d/A5Fba5B1bcxwEmeyoD9nBs.webp
Iris:
https://void.cat/d/44hTcVvhRps6xYYs99QsqA.webp
Snort:
https://void.cat/d/4nJD5TRePuQChM5tzteYbU.webp
Amethyst agrees with Astral which I suspect are both wrong. nostr:npub13sx6fp3pxq5rl70x0kyfmunyzaa9pzt5utltjm0p8xqyafndv95q3saapa nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
Amethyst treats any e tag that was not directly cited in the event as a response to. Isn't it right?
Also, Amethyst and Plebstr render this thread in the same order. Am I missing something?
e-tags should contain markers. "reply" or "root". The event I first saw an issue with, had claimed to be in reply to the OP, while a secondary e-tag referenced my event. So some clients rightfully assume it is a reply to OP as it's explicitly marking it as such a "reply" while others appear to ignore this "reply" "root" marking and follow your assumption. To my surprise, Astral agrees with Amethyst. I do not know blebstr.
This and above event are authored by Snort which uses both markers "reply" and "root" in the sense I thought was correct.
Amethyst fully ignores these markers and rebuilds the thread from scratch. Most of them are wrong.
Yep... You can't trust clients to implement it right. Let's hope it improves over time. But even so, nothing like downloading everything and ordering the thread yourself.
Wait, you sound like you assume there's nothing wrong with Amethyst? Tagging "reply" and "root" is the now preferred way for a reason and as far as I can see, Amethyst marks events as "reply" even when replying to a different event which apparently stems from simply copying the full tag from the replied-to event.
We don't mark anything as reply. That was Plebstr.
Not that i dont want to. I just haven't had the time to do a good job at it.
This event contains 4 plain e-tags which by the old positional rules would be root-e-tag, reply-e-tag, other e-tags.
https://github.com/nostr-protocol/nips/blob/master/10.md?plain=1#L34
In plebstr, we do not add any markers. We are currently working on rebuilding new post, which will add them, but it's not out yet. The current released version we keep e-tags and add new one at the end without markers, it’s not the best but as im saying we are currently working on changing that 😊
By copying the marked e-tags with the "reply" mark, replies look like replies to the parent of the actually replied-to event.
That’s true, thanks for pointing this out and we will fix that in a new version of writing post. We previously followed the currently deprecated scheme without thinking about any markers, mistakes were made and im sorry
Great! I suspect others do the same but it would be hours of work to find out and match to clients. These out-of-order threads bugged me since long and I doubt it's only plebstr unless plebstr has a vastly bigger user base than I had assumed.
Bitcoin beach now called #[2] 🤙
Thanks for sharing.
I used it immediately.👍
