And what if the relay deletes the event after a second due to spam analysis, or it doesn’t forward to the relay the node is on. It’s not a reliable protocol, not designed as one.
Discussion
nostr wallet connect uses ephemeral events, they are never stored and you can’t delete them. Not sure what you’re referring to.
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.
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.
Its basically just realtime pubsub rpc over a dedicated relay. Its no worse than an http server and slightly more convenient because lightning nodes can subscribe to requests and respond in realtime.
But it’s not because you don’t talk directly to the recipient and don’t know if it received your message without an ACK, and only if you also handwave away the “needs to be on the same relay” issue, which isn’t really a trivial problem without a lot of coordination around relay selection, or, more likely, a dedicated proxy run by the wallet vendor….. which you might as well just use directly with HTTP :)