Megalith Node's Lightning Network Docs: https://docs.megalithic.me/
It will never be the same until someone has to unentangled the messes left by vibe coding in a million apps.....
Depends if u are making something client side or server side. But yes, in general with nostr data u are right.
Finally found a query where chatGPT completely got it RIGHT and Grok completely got it wrong... Here is Grok admitting it was wrong... 
If anyone is building for #nostr and needs "support" specifically on the Lightning side -- interacting with Zaps or NWC -- ping me, I'd be interested to help out.
GM, GA, GE, & GN my #nostr
We, ( nostr:npub1uense4apn73tvh4u20tzlp6u72g4kdustzsm0k0sqy6yuwh5jxlsy97y76 /me), discovered yesterday that once I repost/quoted his note, that he did not see it on #primal on his timeline, only on nostr:npub142gywvjkq0dv6nupggyn2euhx4nduwc7yz5f24ah9rpmunr2s39se3xrj0. One must tag, or directly reply to a note for the author to see it. A repost, or a quote may or may not be seen, depending upon the client.
I think this "One must tag, or directly reply to a note for the author to see it." was the behavior I saw recently with Primal. Seems like note threads don't work as expected in Primal.
... And 90% of the challenge of building complex systems is retaining the ability to change them in the future. My theory about "vibe coding" is that it is something that looks great on social media, so that's why you see it everywhere, but in reality, it's not very useful for serious or complex projects.
In my case -- for nostr wallet connect, and for a server-side app I built to analyze images that are published to Nostr apps -- the server needs to directly communicate with relays, there is no "user" who could interact with JS....
You are catching server side errors with sentry or something like that yes?
In my case I was like "give me hotel suggestions in these cities".... I'll find out in couple weeks if the recommendations are good...
I used it recently for some travel stuff. The good part is this: You basically can no longer use Google Search, Tripadvisor, or anything like that for useful travel-related queries, because those are so full of spam and fake reviews. Weirdly you need an AI because you simply cannot trust results about commercial queries ("best hotel in Milan") if those results were made by humans!
nostr:npub1uzee2d5gck0hl7ykwythys36mcm4jm9x8rdpdql3p442458qsuss4qkqac nostr:npub16dhgpql60vmd4mnydjut87vla23a38j689jssaqlqqlzrtqtd0kqex0nkq nostr:npub10xvczstpwsljy7gqd2cselvrh5e6mlerep09m8gff87avru0ryqsg2g437 nostr:npub1xzrkzsrnr83vn7h0udq6tnapwpswy5equlrtkn3nu0e0anlmzynqne0qap We have critical mass for a Los Angeles nostr meetup! It will be happening on April 18th in the West Hollywood area. If you know any other LA-based Nostr users, please tag them in a reply to this message so we can invite them!
nostr:npub1marcan0laywmjprf4m8d34dr8m724a6jxxa56a5wwygcgj23q7nskfwmfg and nostr:npub1vppdwqmhlzhftstq5exturmry4u0pdfm93mqj4zfuuznhclxygfsdatk8w You discussed in your "rails" episode the basic challenge of using rails with Nostr -- rails is just not really made "out of the box" for highly async use cases like Nostr. I have recently had two biggish projects where I has to integrate Rails with nostr -- https://rizful.com/docs/connecting-apps#nostr-wallet-connect-send-and-receive and https://docs.megalithic.me/lightning-services/nsfw-image-detection-for-nostr .... both required a lot of SERVER SIDE communication between Rails and Nostr relays.
I used quite a lot of this https://github.com/wilsonsilva/nostr -- but you'll notice there are a few serious issues -- for one thing, there's no explicit way to actually close a connection with a relay! ( https://github.com/wilsonsilva/nostr/issues/19 ) ....
So after trying a couple different architectures I have currently hit on these rules for server-side development with rails and nostr.
1) Never try to communicate with Nostr relays directly from rails
2) Instead, use a purpose-build "intermediary" application written in Node.js/Typescript... this could be built many different ways but in my case, I have this Node.js application listening to a queue, where it consumes requests from rails....
3) This intermediary application allows your rails application (using multiple threads with something like Puma or many concurrent background jobs) to be "conservative" in its usage of Websocket connections.... you can design this intermediary application so it "re-uses" existing connection to relays, to avoid overwhelming relays, and also, in some cases, to keep connections alive so you can have very low latency with relays -- i.e. not need to constantly connect and disconnect from them.
4) This is just what I have come up with, but I've noticed better latency and better reliability after switching to this strategy.
So Rails can still construct the events, and handle the business logic (Because, as you point out, NOTHING beats Rails + Ruby + Active Record for business logic!), but then it always hands off communication with relays to the intermediary app. (Also, rails will have to listen on a queue to read from the intermediary app, I am using Redis in some cases, RabbitMQ in other cases, and SQS in still other cases, I have found each of these has certain strengths and weaknesses....)
nostr:npub1vppdwqmhlzhftstq5exturmry4u0pdfm93mqj4zfuuznhclxygfsdatk8w and nostr:npub1marcan0laywmjprf4m8d34dr8m724a6jxxa56a5wwygcgj23q7nskfwmfg thanks for your great podcast which I recommend highly - https://www.keypair.fm/ -- I listened to most of the back episodes today while snowshoeing in the San Gabriels
We use Nostream via their docker compose suggestions and it works fairly well.
Everytime I zap someone vie Lightning from my wallet, it takes 5-10 seconds for the zap to settle and for everyone to see it happen on nostr.
Everytime, I think "this could've been an instant nutzap". "Tap, boom. Tap, boom. Zap zap zap. I would be zapping so much more."
The reason a nutzap is instant is obvious. At this point, I hope that everyone knows that a Cashu nutzap is just an instant transfer of an IOU from one user to another.
Let's step back and look at a pure Lightning zap on nostr for a second. We all know that the vast majority of Lightning zaps is effectively an exchange of one custodial IOU against another one as well. Most people use custodial wallets. So why is it still so slow? It's the Lightning settlement between the two custodians that often takes 5-10s to complete. Note, some users actually do run their own node, manage channels, run LNURL servers, etc. But they still get the same UX.
Here is an idea. Let's say a user doesn't want to use Cashu. Pure Lighting maxi which I think is great. I've been a Lightning dev for years before I started working on Cashu. This user could still be nutzapped and even remain fully self-sovereign if they run their own node.
What if the receiving user's Lightning wallet (custodial or non-custodial) was able to melt all nutzaps it receives by watching the nostr wallet ("nutsack") of its user? Either for every nutzap or whenever enough nuts are accumulated, the service could withdraw the nuts to the user's real Lightning wallet.
Effectively, this would improve the zap UX by showing everyone an instant zaps. The receiving user's custodian (or themselves) would have to run something like a nostr-cashu-wallet-watcher on a server to receive while being offline, but they have to run a Lightning node and LNURL and all that anyway (they already have a server).
Even without a server, normal nostr clients without true nutzap support could withdraw all nuts accumulated while they were offline back to their Lightning wallet everytime they come back online. The only real difference to a normal zap is that noe it's the receiver's job to settle via Lightning, not the zap sender's.
Nevertheless, zaps on permissionless social media like in nostr will never be completely trustless. They can't solve the sybil problem for instance. If you want, you can zap yourself an infinite amount of normal Lightning zaps on nostr without moving s single Satoshi. We faked zaps in the early days like crazy just to have fun.
But it actually turns out, all that doesn't really matter too much at all. First, people seem not to abuse the sybil issue. We had fun for a few weeks but then it got uninteresting There is not enough to gain, no algorithm to fool, no benefit of lying (at least not yet). Second, zaps are literally free money given to you from a random person. Why would someone rug you if they want to literally gift you money? It doesn't make much sense.
I think we have a lot more to learn. nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75spz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0dv4ph5 recently said he thinks we have explored 1% of what zaps can be. He might be right. I think the reordering of events that a bearer zap system like with Cashu brings could open new doors for insane UX and it looks like we're actually going to find out. We have zero-config wallets now. Imagine how cool it is to bring your money wherever you go with your nsec.
Keep exploring, cypherpunks. We do live in the best of all times. Bullish on Bitcoin, bullish on Nostr, bullish on Cashu 🧡
Zap latency and zap latency testing is exactly what I am working on currently. I am finding for Rizful nodes I now can get confirmed zap reciepts out from a successful payment in under 1000ms, measured from moment of click of the zap button, when the invoice is requested. I'm actually building a testing/analytics system which will be able to produce timing metrics for any zap target.
