NIP 67: Nostr Wallet Auth

[benthecarman]

There are a lot of technical and UX problems with NWC connection strings, this defines a better way to establish a wallet connection.

Naming and wording can definitely be improved, putting up for review now as I work on an implementation.

[vitorpamplona]

It's strange to require commands from the client. From the list of possible commands listed below, I don't see why it would require any of them. But I may not be understanding what this is about.

[benthecarman]

If I am linking my wallet to a service, the service is going to know which commands it is going to use. This way when the wallet creates the NWC connection it can permission it correctly to only support the necessary commands.

[vitorpamplona]

Ohh so, these are commands the client is requesting from the service and not the other way around. That makes more sense.

[vitorpamplona]

I am confused about the name Auth. The current text doesn't seem to define Authentication mechanisms for clients to follow. Is it coming at a later date or is this just about declaring and identifying compatibility of available commands?

[benthecarman]

@vitorpamplona auth is the best name someone has told me. Happy for suggestions

I think you're not understanding what the purpose of this is. This is for when you want to connect your wallet to a service (something like ZapplePay). Currently, pasting nwc strings causes too much friction and has a lot of downsides that I mention in the intro of the NIP.

It would be better if the user can just scan a QR from their wallet to connect it to the service instead of having proprietary buttons for every wallet or requiring the user to create the connection themself and paste the string into the service.

What we want is a user to know exactly what they are authorizing in their wallet, similar to what you get when you authorize a service with a github account, you get a list of permissions you are giving up in the connection.

[vitorpamplona]

I think you're not understanding what the purpose of this is.

Agree. This whole thing is very confusing. I suggest reviewing the terms and mentions to a "Wallet", the "Nostr Client", "NWC Service" and any other "Service", like ZapplePay (I suppose you are not calling ZapplePay a Nostr client); and clearly identify who does what and when in this protocol. A full example of a complete setup between all these elements and where each string should be used could be very helpful.

This is for when you want to connect your wallet to a service (something like ZapplePay)

Ohhhhh... that should be the first line of this NIP, then. It's really not clear that this is between the Lightning Wallet and the Wallet Connect service.

Currently, pasting nwc strings causes too much friction and has a lot of downsides that I mention in the intro of the NIP.

See, now I am confused again. Why you are using NWC strings to connect to the wallet? Those are for the Nostr client only.

What we want is a user to know exactly what they are authorizing in their wallet

Is a NIP really the best place to document this if this is between the Wallet and the Service?

[benthecarman]

I removed all mentions of nostr clients, I think this is what you're getting hung up on. Nostr is not limited to social media use cases and I think that is what you're getting hung up on.

[benthecarman]

See, now I am confused again. Why you are using NWC strings to connect to the wallet? Those are for the Nostr client only.

That is the problem today, is you have to generate the nwc from the wallet and take it to the app you want to connect to, it makes it very confusing to users (people often have a very hard time connecting to Amethyst from our experience)

Is a NIP really the best place to document this if this is between the Wallet and the Service?

Yes, this should be the standard way to setup a NWC

[fiatjaf]

Why not add this as an optional pre-step to NIP-47?

[vitorpamplona]

It's about your terms, not the social media clients. You are mixing them together or using them interchangeably, which makes it confusing. Probably because on Mutiny they are together, but those are all separate systems for everyone else.

That is the problem today, is you have to generate the nwc from the wallet

See, you did it again. It's not from the Wallet (the lightning wallet doesn't even know nostr exists), it's from the NWC service.

If this PR is between the nostr client and the NWC service, then I go back to my original impression. There is no auth happening here. You are just making a QR to declare which commands are available in the NWC service. The client must read the QR, and somehow send the request for the commands it will use. Then the NWC displays on screen the permission request and, if approved, it creates the access point, and returns the usual uri to be pasted in the app.

Did I get this right?

[benthecarman]

Why not add this as an optional pre-step to NIP-47?

I guess this could be done. It seems I need to get alby to implement anything to get merged into the NIP and they've been really slow.

This flow isn't strictly required for NWC so I think it makes sense as a separate NIP.

[benthecarman]

It's not from the Wallet (the lightning wallet doesn't even know nostr exists), it's from the NWC service.

If the wallet doesn't know nostr exists then payments can't happen. Frankly, it doesn't seem like you understand how NWC works. You keep saying "nostr client" but this term is way to broad, everyone is a nostr client, so this term means nothing.

I think I make it pretty clear, there is a wallet and a service. The wallet is someone like alby, mutiny, nostr-wallet-connect-lnd, something that receives nwc requests and makes payments. The service is someone like Amethyst, Damus, Zapple Pay, who makes requests to the wallet.

[vitorpamplona]

Well, you are definitely the first one to ever call Amethyst a "service". And now I am more confused than ever.

I don't know who does what in this PR.

[benthecarman]

Renamed service to app and added a terms section.

[vitorpamplona]

Much better text! Thanks!

So, the app generates the QR and the Wallet or NWC service now needs a QR Reader.

The issue that I see now is that the app doesn't know beforehand which relay the wallet is using. So generating a QR with the relay string in it is not possible. Or is this a separate relay that should not be used to send Payment Requests in NIP-47?

What happens after the user grants permissions in the Wallet? Does it generate the usual NIP-47 QR? If so, then the QR will contain the private relay the NWC is using and the app can connect to it. That can work.

[benthecarman]

The issue that I see now is that the app doesn't know beforehand which relay the wallet is using. So generating a QR with the relay string in it is not possible. Or is this a separate relay that should not be used to send Payment Requests in NIP-47?

The app picks the relay, so the wallet can just use that relay. This is the relay used throughout.

What happens after the user grants permissions in the Wallet? Does it generate the usual NIP-47 QR? If so, then the QR will contain the private relay the NWC is using and the app can connect to it. That can work.

No, the whole point is to get around the NIP 47 connection string. After the wallet grants permission both sides will have the information they need to do full NIP 47 communication

[vitorpamplona]

After the wallet grants permission both sides will have the information they need to do full NIP 47 communication

How do I get the secret if the NWC generated one for me? What if the NWC only operates on their private relay? Is there a way to send that info back to the app.

[benthecarman]

The example URI uses nostr+walletauth: but I believe Mutiny currently requires nostr+walletauth:// instead. Which one should we use?

Yeah @Semisol said to put it like that in the spec, not sure why

Why space separated lists for required_commands/optional_commands instead of commas?

That is how it is done in the NWC info event so I figured we should do the same here

Instead of budget with max_amount/period, could we separate max_amount and period to reduce unnecessary parsing?

By making them separate parameters people could exclude one of the params but the params only make sense if both are present so I think its better to have as a single param

[jklein24]

I think having a budget is great, but should it really be up to the app to decide this budget? On one hand, it's nice for the app to be able to self-limit (I promise I'll only send 10 sats per day), but I think it might also be nice to give the wallet and even the user the ability to change this budget, like Alby allows today.

[benthecarman]

This is just a recommendation from the app, it is not required by the wallet and can be changed. You can see how we do this with mutiny + zapple pay if you're curious

[nostr-wine]

nostr.wine now supports NWC via NIP-49 as a way to connect to customer wallets and send them invoices when their subscriptions are due. Thanks again Ben!

https://njump.nostr.wine/nevent1qqsz9w3mjvlk4dmuuaxvuqqn32ga95j4mj98upmyh7qhsn9kxhs5mrqzyq7cg2h7e40zj0egke38jvmsfglm3ns4825367g2ky0k5afdgjjz68tw0gf

[Egge21M]

• The example URI uses nostr+walletauth: but I believe Mutiny currently requires nostr+walletauth:// instead. Which one should we use?

The same inconsistency exists in the NWC base spec, which is why I opened #953.

":" is the correct way, as "//" indicates a authority as per RFC 3986. However most implementations that exists in the wild currently use "://"

[benthecarman]

What is the status on getting this merged? I think there are now 4 implementations in the wild now

• mutiny
• zapple pay
• prisms
• nostr.wine

[benthecarman]

Seems like 49 was taken so changed to 67

[benthecarman]

[fiatjaf]

Just help me understand: this is just an inversion of the connect flow of NIP-47?

NIP-46 defines both connect flows: from client to signer and from signer to client. After the initial connection everything is the same, which seems to be the case here.

If that is the case then I would like to read this more carefully and try to merge it into NIP-47.

[benthecarman]

If that is the case then I would like to read this more carefully and try to merge it into NIP-47.

Okay I can reformat it to do that

[jklein24]

@benthecarman I really like this proposal and hope it's merged (either here or to NIP-47)! One question - do you think it might make sense for the confirmation event to include an optional budget as well? I know with Alby's NWC UI, the user can manually change the budget, etc. If the app requests a specific budget, but the wallet/user grants a different one, does the app need to know that? I realize that with NWC, the app isn't made aware of a budget restriction except for via QUOTA_EXCEEDED errors, but in this case if the app specifically requests a budget, it seems more relevant.

[jklein24]

Why is this needed if it's also the base path of the URI? Is that a different app pubkey?

[benthecarman]

this is meant to be different the base path, this is used to socially tag the connection so you don't need to use the same keys you use for nwc that you use for your profile

[benthecarman]

do you think it might make sense for the confirmation event to include an optional budget as well?

yeah that's a good idea

[benthecarman]

i have some free time next week, I'll try to restructure this to be an edit to NIP-47 like @fiatjaf suggested

[vitorpamplona]

Are we doing this? Can we clear all debates over this and move to either implement/merge or close it?