pull down to refresh
167 sats \ 10 replies \ @supertestnet 18 Aug 2024 \ parent \ on: SN release: autowithdraw fixes. Trouble with attached wallets? Ask here! meta
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:
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
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
We might exclusively use
get_info
then.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.
reply
Ohh, interesting, so we should fetch the info event as a command to get the permissions for the current connection
reply