I didn't get that
Discussion
NIP 47 is a house of cards :)
how so
It’s built in using nostr as a reliable delivery protocol, which it isn’t. That leads to random failures as relays handle spam.
If my random zap doesn't make it to my node, not really a big deal.
Also can use private relays so it's less of a problem.
For zaps it’s okay, but I’ve seen plenty of speculation about using it for General payment handling, which is definitely not a good direction. If we need something for this (we do) we should build something that’s robust and general, not “only works if you don’t care about reliability”.
If you’re using a private relay you might as well just use lnurl/http/onion messages/etc.
Luckily this kinda thing is pretty trivial with android intents (literally the bitcoinj payment channels from 7-8 years ago worked this way!) and iOS deep linking can do something similar. Order of magnitude less complexity than nostr if you don’t already have a nostr client.
Thanks for sharing your insights #[5]
This is why I added the command results NIP. Damus will retry requests that don’t get an OK result from the relay. Works more like email now.
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.
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 :)