I tried using @supertestnet's very cool Bankify wallet to connect via NWC, and received this error message:
EOSE received without info event
221 sats \ 14 replies \ @ek 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
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
44 sats \ 4 replies \ @ek 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
no problem :D
thank you for reporting the issue!
reply
10 sats \ 2 replies \ @ek 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!
reply
0 sats \ 1 reply \ @ek 20 Aug
We might exclusively use get_info then.
212 sats \ 2 replies \ @ek 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 19 Aug
Ohh, interesting, so we should fetch the info event as a command to get the permissions for the current connection
reply
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