pull down to refresh
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
Actually wait, the spec DOES say get_info is a query which you are supposed to respond to:
What gives?
reply
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:
Search for "The info event should be a replaceable event..."
reply
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
no problem :D
thank you for reporting the issue!
reply
reply
reply
it certainly makes the implementation simpler -- I didn't even realize there was supposed to be a get_info replaceable event because I don't think it's mentioned on nwc.dev
**EDIT: okay I found it, they do mention it: https://docs.nwc.dev/bitcoin-lightning-wallets/getting-started
Theory of Operation
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. 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 aninfo
(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
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.
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
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
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
createNWCconnection
function and searching for 13194 (the info event kind), I think you are not publishing the info event as per spec: