As in deleted/dropped before the sending node sees them, presumably due to a temporary connection failure cause they’re trying to use tor for privacy.
Discussion
But you should use a relay that is ran by your custodian only for this purpose.
So…. Just use HTTP? Like nostr is a lot of additional code just to get HTTP/pub/sub with a vendor-operated server.
I would have been fine with http
Thats called the lndhub api but it was not suited for 2 reasons. Too difficult to self host and yet another api for nostr clients to implement
Nostr is yet another protocol for ln nodes to implement :). Nostr is also yet another protocol for every application that wants to send money without interaction (poker app, etc) to implement. HTTP REST over a proxy is at least trivial to implement.
Nostr wallet connect is very similar to ethereum wallet connect, which is widely used. Clearly its not that bad of an idea
Indeed, there’s definitely a need, but doing it via a remote RPC isnt really a good approach if you want to support noncustodial wallets and we don’t need something so general for a payments platform. We’re not designing a “world computer”, we can build something for payments :).
More generally, use intents! We’re talking about an app talking to another app, there’s a whole suite of APIs built exactly for this purpose.
most non-nostr apps shouldn’t need to care about NWC, I don’t really see a problem. If another app needs NWC like functionality then they should propose a spec for their use case. nostr just happens to be popular atm and it makes sense to use relays for rpc in this context.
But “just propose another spec” adds up a ton over time, each time we do that we’re asking every lightning wallet to implement yet more code, and the compatibility matrix of lightning wallets becomes yet more complicated.
This is already a huge pain point for users today - Lightning payment instruction formats are complicated and not reliably implemented across the ecosystem. Please please let’s not make it worse.