NIP-42 Extension: auth-by-payment

[Origami74]

This Extension of NIP-42 allows relays to add an extra NUT-18 argument to AUTH messages, that gives the user the option to authorize by providing a cashu payment. This allows relay operators to monetize with pay-as-you-go connections without the need to keep track of subscriptions and/or whitelists.

This would allow the user to use ephemeral pubkeys to sign this message as well, so giving them more privacy.

I'm not sure wether or not the payment request should be encoded or just be a JSON as is currently the case. Encoding it would make it easier to detect and validate, at the same time there is no human interaction involved so encoding the token might be overkill.

[staab]

I think it makes sense to add payment to the auth flow, but this approach has a few problems:

• You don't yet know who the user is. It seems like it would be better (more flexible) to wait until after the auth challenge has been returned to return an additional challenge (auth-required: Pay me!, <invoice>)
• Frequency of auth depends on client implementation — clients might close connections and re-open, making the user pay more times than others.

[Origami74]

I think it makes sense to add payment to the auth flow, but this approach has a few problems:

• You don't yet know who the user is. It seems like it would be better (more flexible) to wait until after the auth challenge has been returned to return an additional challenge (auth-required: Pay me!, <invoice>)
• Frequency of auth depends on client implementation — clients might close connections and re-open, making the user pay more times than others.

To the first point I would like to point out that that's the feature, not a bug. Nostr allows us to not care who the customer is, as long as they pay. You pay, you get the service, no KYC required.

To your point of handling of closing and potentially re-opening connections: I would say the relay is free to still retain a session for the pubkey that signed + paid the initial AUTH event and allow a reconnected client to sign again (same pubkey) without having to pay. The client would then just use the residual 'balance' of whatever it bought (time/KiB/etc).

[staab]

You pay, you get the service, no KYC required.

Except the AUTH flow requires the client to sign an event with the user's key. If you're going for anonymous pay-to-access (which actually makes more sense), I would add a new message type.

[vitorpamplona]

The issue I have with this is that the invoice doesn't explain to the user what is he/she paying for. It's really hard to get them to pay without an explanation.

Take a look at #901

That spec allows the relay to ask for payment at any time with a complete description and maybe multiple invoices. It can be used in many ways. And Clients can show or not the message.

On Amethyst, if the relay is part of the user's list or if this is a DM relay from a follow or somebody you have been chatting with for some time, then it shows the message. If we are connecting to random relays to just download events, then it won't display.

[mikedilger]

I am against tying this into AUTH. You could get the same result without bespoiling the AUTH system. After all, paying off a relay isn't actually AUTH, even if it does affect the policies the relay uses.

[fiatjaf]

What is the use case? AUTH to me is more about knowing who is calling then trying to charge people. If you're charging for storing events then you can get that information from the event signer, AUTH is for knowing who is on the other side to decide what events you will return to them, mostly.

Maybe if we are more clear about the use case we can come up with a better solution.

(By the way, just letting you know, the best solution to me is always to have the relay host an HTML webpage where someone can go and fill a form or something like that, but I'll change my answer giving the right circumstances.)

[Semisol]

Charging scheme != Authentication

[Origami74]

After all, paying off a relay isn't actually AUTH

AUTH to me is more about knowing who is calling then trying to charge people.

Charging scheme != Authentication

I think i failed to see that this NIP was specifically intended for authentication (who) only and not for authorization (what), which are 2 different but related things. My proposal would indeed add authorization to this NIP. I understand the argument to have this authorization scheme defined separately. In that case, what do you guys think that should look like though, would it require an entirely different format?

Maybe if we are more clear about the use case we can come up with a better solution.

I implemented it in Nostr Epoxy. Which is a websocket that runs in front of a relay. By default a user can just interact with it like any relay and it listens for custom ["proxy", ..., ... ] commands to proxy to other relays. It authorizes a user to proxy for X minutes by charging sats (cashu) but does not need or want to keep track of a user's identity.

At first i had implemented the payment flow it under the same ["proxy", ..., ... ] command but it made sense to me to make it more universal, as it's very likely that other services would want to use this kind of flow as well. One example i can think of would be pay-per-query relays, like expensive search operations.

As for your remarks @vitorpamplona about the person knowing what they pay for... I made the assumption in here that the person connecting is aware of what they're trying to get access to and would know through other discovery mechanism's that this proxy/relay will charge sats. My only worry would be that there's too many possible applications that putting the what/why you are paying in the request itself might limit what you can do with it. Can't that information be shared through announcement events specific to each use-case? It's what i'm doing with Epoxy.