@natalia @StillStackinAfterAllTheseYears @kepford @fed this should be fixed now. Sorry it took a bit. I had to overhaul something I was resistant to changing.
Quite a few people have had some trouble with other wallets. If you need some help troubleshooting, ask here and @ek and I will help or fix it if it's broken.
Can confirm that autowithdraw kicked in for me. Thanks!
FYI, autowithdraw to Blixt works fine through lightning address connection.
I tried using @supertestnet's very cool Bankify wallet to connect via NWC, and received this error message:
@supertestnet, from reading your
createNWCconnectionfunction and searching for 13194 (the info event kind), I think you are not publishing the info event as per spec:Seems like you're assuming it's a command like the others. That would actually be cool since it's makes the spec easier but it's unfortunately not the spec.
Do you have plans to publish the info event when you create the NWC connection? I can also submit a PR if you want.
Do you know if there are more implementations that do what you're doing? Maybe we should try to fetch the info event like a command even if it's not part of the spec.
But this is just another reason that we should move to test payments so we don't rely on this info event getting published by wallets anymore.
fixing now
you are correct that I assumed get_info is an ephemeral response to a query, like almost everything else in the spec, due probably to not reading carefully
Actually wait, the spec DOES say get_info is a query which you are supposed to respond to:
https://docs.nwc.dev/reference-api/overview/get_info
What gives?
ok it does both now -- if you query it, it responds the same as it did before now, but it also creates or replaces the replaceable "info" event on startup
@ek let me know if it works for you now
For those seeking the spec on how to do the replaceable info event, the spec is here:
https://github.com/nostr-protocol/nips/blob/master/47.md
Search for "The info event should be a replaceable event..."
Works now, thank you!
Maybe we should also support both (as a replaceable event and as a command) if docs.nwc.dev lists it only as a command.
no problem :D
thank you for reporting the issue!
Oh, I just realized that
get_infoas a command is indeed part of the spec. It's the last command.I didn't realize that. So it's indeed also part of the official spec!
Oh, mhh, the official spec ("official" as mentioned here) says this in Theory of Operation:
Afaik, docs.nwc.dev is from @Alby. Let's see what they have to say about this đź‘€
We publish the 13194 event to announce what capabilities the wallet service supports, but this is done only once for the entire service.
The get_info command however is specific to the app connection, and can have a different list of commands based on the permissions granted to that app.
Ohh, interesting, so we should fetch the info event as a command to get the permissions for the current connection
FYI, @supertestnet secrets worked for primal. I can zap. I realize this isn't a viable solution for either SN or primal. I'm just playing around. It would be great though if Bankify becomes a viable SN option.
I've given some thought as to how to make Bankify not require an open browser tab. Here are my thoughts so far.
There are a few services that let you spin up a cloud computer (a "virtual private service" or VPS) and let you pay monthly via lightning. I could give a button to the user where, if the click it, it shows them a lightning invoice, and if they pay it, it automatically spins up a VPS for them, installs the requisite software, and then hosts their wallet there, with a monthly reminder when it's time to pay their bill.
But there are a few parts of that job that are tricky: these services usually email you the log in credentials for your virtual computer, and you have to get those credentials, then log in in order to install the software needed by the user. So in order to automate this I would have to set up some service that can receive emails, parse them, automatically use parts of the parsed email to log in to a VPS and install some software, then somehow deny myself future access by deleting the password or something like that.
And I would also have to show the user some sort of loading animation for, like, several minutes or so, and hope they don't just get mad about the delay and "x out" partway through. This would also break if the VPS host ever changes their email format, meaning I would have to maintain and update the software occasionally, and users would have to be made aware that they are trusting the VPS host to (1) stick around (2) not read their private keys and steal their money.
This is all very imperfect so I seek a better solution. When there are free custdial services available, how do you convince users to pay for the-same-thing-but-worse?
I just want you to know I just zapped this reply with Bankify. I'm on mobile and just saved the Bankify page as what I consider a PWA. The zap was really very fast. Not much different than an SN zap. I'm only keeping a very small amount in the wallet. I know the risks
Not sure what's happening, but I'm not able to make it work. The logs are different, but it seems to still be complaining about msats over sats.
https://m.stacker.news/46293
What's the wallet source? This error means lnbits is returning an invoice for an amount larger than we requested. In this case, it's a lot more than we requested.
Lnbits using PhoenixD. Here is the invoice it is giving.
https://m.stacker.news/46302
It looks like it's charging SN to open a channel, but it might also be poor support for msats in lnbits. We are trying to pay you 2,762 sats and it wants us to pay 27,878 sats.
Shouldn't be a channel charge, that phoenixd instance got plenty inbound liquidity. Weird, it's like the invoice further multiplies the sats by a thousand before charging.
It looks like lnbits doesn't support msats: https://github.com/lnbits/lnbits/issues/2009
The price needs to go higher for enough people to care about msats, lol
I know, but the lightning specs are all in msats, so all these non-msat APIs will have to be rewritten eventually, and it's weird to have APIs acting like they're receiving direct user input.
I've submitted a fix that doesn't use msats with lnbits. Let me know if that finally does the trick.
I can confirm, auto withdrawal worked now. Thanks!
Thanks for your patience/help troubleshooting!
It'd be a pretty obvious msats/sats confusion if it were 1000x as much, but maybe it's doing something else funky. It works fine in our testing with lnd, but maybe phoenixd doesn't like msats.
I'll review this deeply tomorrow and see if there's something we can do.
deleted by author
Trying to connect to a node through NWC. SN doesn't have a wallet qr option for NWC. I have generated a secrets string, but obviously that's not sufficient to connect. Any suggestions?
Oh, we could add a QR scanner for NWC similar to withdrawals ... but why isn't the secrets string enough? You only need the string that starts with nostr+walletconnect://. Is that not it?
That's the problem. I'm using the oak node app and the secrets string does not contain nostr+walletconnect://.
interesting, will take a look
I saw some of the discussion threads. Was it an issue trying to specify amounts in millisats in withdrawals to LN Addr providers that didn’t support it?
Yep, some of them round the millisats to sats and others, more appropriately, return an error.
Who takes specs seriously anyway /s
deleted by author