SN release: autowithdraw fixes. Trouble with attached wallets? Ask here!
1283 sats \ 39 comments \ @k00b 17 Aug meta
zaps forwarded to @ek (50%)
@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.
write
preview
related posts
195 sats \ 0 replies \ @StillStackinAfterAllTheseYears 17 Aug
Can confirm that autowithdraw kicked in for me. Thanks!
reply
223 sats \ 0 replies \ @siggy47 17 Aug
FYI, autowithdraw to Blixt works fine through lightning address connection.
reply
43 sats \ 0 replies \ @Natalia 17 Aug
worked! thanks ✌🏽 and I looked at the logs, cute!
wallet does not support msats so we floored X msats to nearest sat X msats
reply
227 sats \ 15 replies \ @siggy47 17 Aug
I tried using @supertestnet's very cool Bankify wallet to connect via NWC, and received this error message:
EOSE received without info event
reply
221 sats \ 14 replies \ @ek fwd 17 Aug
@supertestnet, from reading your createNWCconnection function and searching for 13194 (the info event kind), I think you are not publishing the info event as per spec:
The info event should be a replaceable event that is published by the wallet service on the relay to indicate which commands it supports.
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.
reply
167 sats \ 10 replies \ @supertestnet 18 Aug
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
reply
256 sats \ 9 replies \ @supertestnet 18 Aug
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?
reply
1103 sats \ 5 replies \ @supertestnet 18 Aug
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..."
reply
44 sats \ 4 replies \ @ek fwd 18 Aug
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.
reply
208 sats \ 3 replies \ @supertestnet 18 Aug
no problem :D
thank you for reporting the issue!
reply
10 sats \ 2 replies \ @ek fwd 20 Aug
Oh, I just realized that get_info as 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!
view replies
212 sats \ 2 replies \ @ek fwd 18 Aug
Oh, mhh, the official spec ("official" as mentioned here) says this in Theory of Operation:
Theory of Operation
  1. Users who wish to use this NIP to send lightning payments to other nostr users must first acquire a special "connection" URI from their NIP-47 compliant wallet application. The wallet application may provide this URI using a QR screen, or a pasteable string, or some other means.
  2. The user should then copy this URI into their client(s) by pasting, or scanning the QR, etc. The client(s) should save this URI and use it later whenever the user makes a payment. The client should then request an info (13194) event from the relay(s) specified in the URI. The wallet service will have sent that event to those relays earlier, and the relays will hold it as a replaceable event.
Afaik, docs.nwc.dev is from @Alby. Let's see what they have to say about this 👀
reply
198 sats \ 1 reply \ @rolznz 19 Aug
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.
reply
100 sats \ 0 replies \ @ek fwd 19 Aug
Ohh, interesting, so we should fetch the info event as a command to get the permissions for the current connection
reply
114 sats \ 2 replies \ @siggy47 17 Aug
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.
reply
377 sats \ 1 reply \ @supertestnet 18 Aug
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?
reply
100 sats \ 0 replies \ @siggy47 18 Aug
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
reply
133 sats \ 12 replies \ @fed 17 Aug
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
reply
1 sat \ 11 replies \ @k00b OP 17 Aug
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.
reply
151 sats \ 10 replies \ @fed 17 Aug
Lnbits using PhoenixD. Here is the invoice it is giving.
https://m.stacker.news/46302
reply
10 sats \ 9 replies \ @k00b OP 17 Aug
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.
reply
0 sats \ 7 replies \ @fed 17 Aug
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.
reply
103 sats \ 2 replies \ @k00b OP 17 Aug
It looks like lnbits doesn't support msats: https://github.com/lnbits/lnbits/issues/2009
reply
100 sats \ 1 reply \ @ek fwd 17 Aug
The price needs to go higher for enough people to care about msats, lol
reply
0 sats \ 0 replies \ @k00b OP 17 Aug
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.
reply on another page
21 sats \ 2 replies \ @k00b OP 18 Aug
I've submitted a fix that doesn't use msats with lnbits. Let me know if that finally does the trick.
reply
1057 sats \ 1 reply \ @fed 18 Aug
I can confirm, auto withdrawal worked now. Thanks!
reply
0 sats \ 0 replies \ @k00b OP 18 Aug
Thanks for your patience/help troubleshooting!
reply on another page
0 sats \ 0 replies \ @k00b OP 17 Aug
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.
reply
10 sats \ 0 replies \ @fed 17 Aug
deleted by author
reply
103 sats \ 3 replies \ @siggy47 17 Aug
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?
reply
43 sats \ 2 replies \ @ek fwd 17 Aug
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?
reply
104 sats \ 1 reply \ @siggy47 17 Aug
That's the problem. I'm using the oak node app and the secrets string does not contain nostr+walletconnect://.
reply
43 sats \ 0 replies \ @ek fwd 17 Aug
interesting, will take a look
reply
33 sats \ 2 replies \ @WeAreAllSatoshi 17 Aug
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?
reply
100 sats \ 1 reply \ @k00b OP 17 Aug
Yep, some of them round the millisats to sats and others, more appropriately, return an error.
reply
100 sats \ 0 replies \ @WeAreAllSatoshi 17 Aug
Who takes specs seriously anyway /s
reply