forgejo-admin/nuts

Fork 0

NUT-24: HTTP Payment required #239

Merged

hzrd149 merged 9 commits from 402 into main

2025-06-26 11:33:45 +00:00

hzrd149 commented

2025-03-24 17:03:08 +00:00

(Migrated from github.com)

This PR adds NUT-24 that describes how the HTTP 402 status code + an X-Cashu header can be used to require payment for http resources
readable version

The goal for this NUT is to keep it tightly coupled to HTTP and keep all communication in-band to reduce complexity.

This PR adds NUT-24 that describes how the HTTP 402 status code + an `X-Cashu` header can be used to require payment for http resources [readable version](https://github.com/hzrd149/cashu-nuts/blob/402/23.md) The goal for this NUT is to keep it tightly coupled to HTTP and keep all communication in-band to reduce complexity.

❤️ 1 🚀 1

thesimplekid (Migrated from github.com) reviewed

2025-03-24 17:09:11 +00:00

23.md

If the server receives tokens from a mint that is not in the `mints` array, an incorrect `unit`, or an insufficient amount of tokens it SHOULD respond with a HTTP `400` status code.

Should we also state that the server SHOULD NOT redeem these tokens?

```suggestion If the server receives tokens from a mint that is not in the `mints` array, an incorrect `unit`, or an insufficient amount of tokens it SHOULD respond with a HTTP `400` status code. ``` Should we also state that the server SHOULD NOT redeem these tokens?

callebtc commented

2025-03-26 13:53:03 +00:00

(Migrated from github.com)

This should reuse the payment request from NUT-18 and specify which fields need to be set https://github.com/cashubtc/nuts/pull/243

👍 1

callebtc (Migrated from github.com) reviewed

2025-03-27 10:28:15 +00:00

23.md

The server might want to melt them, I think it's better to leave this to the implementor.

callebtc commented

2025-03-27 13:58:40 +00:00

(Migrated from github.com)

Looks ready. Please leave your reviews. We usually wait for an implementation before we merge.

gandlafbtc (Migrated from github.com) reviewed

2025-03-27 14:36:42 +00:00

23.md

If the tokens are to be validated offline, they should also be checked for refund keys and timelock expiry

callebtc (Migrated from github.com) reviewed

2025-03-27 15:08:54 +00:00

23.md

I implied that in it MUST validate the P2PK script

I implied that in _it MUST validate the P2PK script_

Egge21M commented

2025-03-27 15:30:44 +00:00

(Migrated from github.com)

This is great! I have been waiting for this. For anyone building an implementation for this, here is an endpoint to test against: https://cashu402.fly.dev/secret

Repo: https://github.com/Egge21M/cashu402

This is great! I have been waiting for this. For anyone building an implementation for this, here is an endpoint to test against: https://cashu402.fly.dev/secret Repo: https://github.com/Egge21M/cashu402

positiveblue commented

2025-03-27 16:17:47 +00:00

(Migrated from github.com)

It's nice to see more people building on the HTTP 402 🎉

eCash has something really distinct and it's that "the token is the money" which means that people can use it as "proof of payment" (you send it to me and I claim it instantly). This is different from other payment methods where you can do pull based payments (ex: credit cards) or push based but you need to check if the payment was completed outbound (ex: Bitcoin)

We have been working for a while with a generic flow that supports all kind of payment methods. The trade offs for ecash is

Cons:
- One extra HTTP trip
Pros:
- One integration, many payment methods
- Support for multiple offers (ex: you need to become a paid user but can be professional, pro or enterprise)
- Allows solutions that use third party gateways (you pay somewhere else and they send me a webhook that the offer was paid, easy to swap with current solutions like stripe)

I understand why you want to create a NUT for this. Same of why x402 exists for "strictly on chain payments" but even in that case I would try to bake in the "multiple offer support" in.

It's nice to see more people building on the `HTTP 402` 🎉 eCash has something really distinct and it's that "the token is the money" which means that people can use it as "proof of payment" (you send it to me and I claim it instantly). This is different from other payment methods where you can do pull based payments (ex: credit cards) or push based but you need to check if the payment was completed outbound (ex: Bitcoin) We have been working for a while with a [generic flow that supports all kind of payment methods](https://www.l402.org). The trade offs for ecash is - Cons: - One extra HTTP trip - Pros: - One integration, many payment methods - Support for multiple offers (ex: you need to become a paid user but can be professional, pro or enterprise) - Allows solutions that use third party gateways (you pay somewhere else and they send me a webhook that the offer was paid, easy to swap with current solutions like stripe) I understand why you want to create a NUT for this. Same of why [x402](https://github.com/coinbase/x402) exists for "strictly on chain payments" but even in that case I would try to bake in the "multiple offer support" in.

👀 1

trbouma commented

2025-03-28 15:36:26 +00:00

(Migrated from github.com)

If you plan to keep a int I suggest that you clarify to specify that it be fractional unit of the currency for a 402 payment required. Otherwise, you'll need a float type, if you are going to specify a fiat currency e.g., 0.01 USD

I prefer sticking to an int so the proposed change would be:

a: The amount required in the specified fractional unit

For background, every currency has a fractional unit and number to base
You can see below for example the Ukranian, hyrvnia has a fractional unit of kopeck and the number to base is 100
Similarly, the USD is the cent and the number to base is 100
Others like the Uganda Shilling is 1:1 (base unit same as fractional unit)
Finally, for BTC the fractional unit is sat, and the number to base is 100000000

I think this would be the best way to express pricing for 402 micropayment - in the fractional unit versus the base unit. A 1 cent per view versus $0.01 per view or 1 sat per view versus 0.000000000001BTC per view

You can peruse my currency table dump below for more examples.

currency_code,currency_rate,currency_symbol,currency_description,refresh_time,fractional_unit,number_to_base
UAH,999105.81,₴,Ukrainian hryvnia,,kopeck,100
VND,699594225.70,₫,Viet Nam Dong,,hao,10
XOF,17523097.96,R,West African Franc,,centime,100
AWG,52449.9714,f,Aruba florin,,centime,100
BTC,1,B,Bitcoin,,satoshi,100000000
UGX,109976512.00,R,Uganda Shillings,,shilling,1
BTN,2441712.23,Nu,Bhutanese Ngultrum,,chetrum,100
SAT,100000000,≐,satoshis,,msat,1000
NCR,1000000.0,nc,Narnia Crescent,,sat,100
NSL,1000000.0,៛,Narnia Silverleaf,,sat,100
XCD,275724.46,EC$,Eastern Caribbean Dollars,2025-01-28 06:00:00.623873,cent,100
CZK,2472350.09,Kč,Czech Koruna,2025-01-28 06:00:00.623873,heller,100
DKK,735253.67,kr,Danish Krone,2025-01-28 06:00:00.623873,ore,100
BNA,564850,bn,Bananas,,banana,1
HKD,800305.1,$,Hong Kong Dollars,2025-01-28 06:00:00.623873,cent,100
HRK,473845.0,kn,Croatia Kuna,2025-01-28 06:00:00.623873,kuna,1
HUF,40257665.02,Ft,Hungary Forint,2025-01-28 06:00:00.623873,filler,100
INR,8892916.05,R,Indian Rupees,2025-01-28 06:00:00.623873,paisa,100
ISK,13429936.32,kr,Iceland Krona,2025-01-28 06:00:00.623873,eyrir,100
KRW,148500613.63,₩,Korean Won,2025-01-28 06:00:00.623873,jeon,100
NZD,181642.41,$,New Zealand Dollar,2025-01-28 06:00:00.623873,cent,100
PLN,414457.54,zł,Poland Zloty,2025-01-28 06:00:00.623873,grosz,100
RON,490130.83,lei,Romania Leu,2025-01-28 06:00:00.623873,ban,100
RUB,10054395.45,₽,Russian Rubles,2025-01-28 06:00:00.623873,kopeck,100
SGD,138899.68,$,Singapore Dollars,2025-01-28 06:00:00.623873,cent,10
THB,3485525.46,ϯ,Thailand Baht,2025-01-28 06:00:00.623873,satang,100
TRY,3674040.93,₺,Turkey Lira,2025-01-28 06:00:00.623873,kurus,100
TWD,3383202.44,NT$,Taiwan New Dollars,2025-01-28 06:00:00.623873,cent,100
PHP,5941092.62,₱,Philippine Pesos,2025-01-28 06:00:00.623873,sentimo,100
NGN,162571200.0,₦,Nigerian Naira,2025-01-28 06:00:00.623873,kobo,100
NOK,1219284.0,kr,Norway Krone,2025-01-28 06:00:00.623873,ore,100
PKR,28689035.29,₨,Pakistan Rupee,2025-01-28 06:00:00.623873,paisa,100
SAR,375164.31,﷼,Saudia Arabia Riyal,2025-01-28 06:00:00.623873,halala,100
ZAR,1950854.4,R,South Africa Rand,2025-01-28 06:00:00.623873,cent,100
IDR,975427200.0,Rp,Indonesia Rupiah,2025-01-28 06:00:00.623873,sen,100
MXN,2106754.21,$,Mexican Pesos,2025-01-28 06:00:00.623873,centavo,100
QAR,375164.31,﷼,Qatar Riyal,2025-01-28 06:00:00.623873,dirham,100
ARS,107836579.79,$,Argentina Dollars,2025-01-28 06:00:00.623873,centavo,100
BRL,605534.29,R$,Brazilian Real,2025-01-28 06:00:00.623873,centavo,100
CHF,93110.99,CHF,Swiss Franc,2025-01-28 06:00:00.623873,rappen,100
SEK,1083808.0,kr,Sweden Krona,2025-01-28 06:00:00.623873,ore,100
CLP,101427455.56,$,Chilean Peso,2025-01-28 06:00:00.623873,centavo,100
KYD,85100.14,CI$,Cayman Islands Dollars,2025-01-28 06:00:00.623873,cent,100
CAD,146861.86,$,Canadian Dollars,2025-01-29 14:23:50.320343,cent,100
EUR,97809.2,€,Euro,2025-01-29 14:23:50.320588,cent,100
GBP,81857.61,£,British Pounds,2025-01-29 14:23:50.320769,pence,100
JPY,15805071.28,¥,Japanese Yen,2025-01-29 14:23:50.320945,sen,100
USD,101724.26,$,United States Dollars,2025-01-29 14:23:50.321121,cent,100
AUD,163546.06,$,Australian Dollars,2025-01-29 14:23:50.321297,cent,100
CNY,729474.84,¥,Chinese Yuan Renminbi,2025-01-29 14:23:50.321471,jiao,10

If you plan to keep `a int` I suggest that you clarify to specify that it be `fractional unit` of the currency for a 402 payment required. Otherwise, you'll need a `float` type, if you are going to specify a fiat currency e.g., 0.01 USD I prefer sticking to an `int` so the proposed change would be: `a: The amount required in the specified fractional unit` For background, every currency has a `fractional unit` and `number to base` You can see below for example the Ukranian, `hyrvnia` has a fractional unit of `kopeck` and the `number to base` is 100 Similarly, the `USD` is the `cent` and the `number to base` is 100 Others like the Uganda Shilling is 1:1 (base unit same as fractional unit) Finally, for `BTC` the fractional unit is sat, and the number to base is 100000000 I think this would be the best way to express pricing for 402 micropayment - in the fractional unit versus the base unit. A 1 cent per view versus $0.01 per view or 1 sat per view versus 0.000000000001BTC per view You can peruse my currency table dump below for more examples. ``` currency_code,currency_rate,currency_symbol,currency_description,refresh_time,fractional_unit,number_to_base UAH,999105.81,₴,Ukrainian hryvnia,,kopeck,100 VND,699594225.70,₫,Viet Nam Dong,,hao,10 XOF,17523097.96,R,West African Franc,,centime,100 AWG,52449.9714,f,Aruba florin,,centime,100 BTC,1,B,Bitcoin,,satoshi,100000000 UGX,109976512.00,R,Uganda Shillings,,shilling,1 BTN,2441712.23,Nu,Bhutanese Ngultrum,,chetrum,100 SAT,100000000,≐,satoshis,,msat,1000 NCR,1000000.0,nc,Narnia Crescent,,sat,100 NSL,1000000.0,៛,Narnia Silverleaf,,sat,100 XCD,275724.46,EC$,Eastern Caribbean Dollars,2025-01-28 06:00:00.623873,cent,100 CZK,2472350.09,Kč,Czech Koruna,2025-01-28 06:00:00.623873,heller,100 DKK,735253.67,kr,Danish Krone,2025-01-28 06:00:00.623873,ore,100 BNA,564850,bn,Bananas,,banana,1 HKD,800305.1,$,Hong Kong Dollars,2025-01-28 06:00:00.623873,cent,100 HRK,473845.0,kn,Croatia Kuna,2025-01-28 06:00:00.623873,kuna,1 HUF,40257665.02,Ft,Hungary Forint,2025-01-28 06:00:00.623873,filler,100 INR,8892916.05,R,Indian Rupees,2025-01-28 06:00:00.623873,paisa,100 ISK,13429936.32,kr,Iceland Krona,2025-01-28 06:00:00.623873,eyrir,100 KRW,148500613.63,₩,Korean Won,2025-01-28 06:00:00.623873,jeon,100 NZD,181642.41,$,New Zealand Dollar,2025-01-28 06:00:00.623873,cent,100 PLN,414457.54,zł,Poland Zloty,2025-01-28 06:00:00.623873,grosz,100 RON,490130.83,lei,Romania Leu,2025-01-28 06:00:00.623873,ban,100 RUB,10054395.45,₽,Russian Rubles,2025-01-28 06:00:00.623873,kopeck,100 SGD,138899.68,$,Singapore Dollars,2025-01-28 06:00:00.623873,cent,10 THB,3485525.46,ϯ,Thailand Baht,2025-01-28 06:00:00.623873,satang,100 TRY,3674040.93,₺,Turkey Lira,2025-01-28 06:00:00.623873,kurus,100 TWD,3383202.44,NT$,Taiwan New Dollars,2025-01-28 06:00:00.623873,cent,100 PHP,5941092.62,₱,Philippine Pesos,2025-01-28 06:00:00.623873,sentimo,100 NGN,162571200.0,₦,Nigerian Naira,2025-01-28 06:00:00.623873,kobo,100 NOK,1219284.0,kr,Norway Krone,2025-01-28 06:00:00.623873,ore,100 PKR,28689035.29,₨,Pakistan Rupee,2025-01-28 06:00:00.623873,paisa,100 SAR,375164.31,﷼,Saudia Arabia Riyal,2025-01-28 06:00:00.623873,halala,100 ZAR,1950854.4,R,South Africa Rand,2025-01-28 06:00:00.623873,cent,100 IDR,975427200.0,Rp,Indonesia Rupiah,2025-01-28 06:00:00.623873,sen,100 MXN,2106754.21,$,Mexican Pesos,2025-01-28 06:00:00.623873,centavo,100 QAR,375164.31,﷼,Qatar Riyal,2025-01-28 06:00:00.623873,dirham,100 ARS,107836579.79,$,Argentina Dollars,2025-01-28 06:00:00.623873,centavo,100 BRL,605534.29,R$,Brazilian Real,2025-01-28 06:00:00.623873,centavo,100 CHF,93110.99,CHF,Swiss Franc,2025-01-28 06:00:00.623873,rappen,100 SEK,1083808.0,kr,Sweden Krona,2025-01-28 06:00:00.623873,ore,100 CLP,101427455.56,$,Chilean Peso,2025-01-28 06:00:00.623873,centavo,100 KYD,85100.14,CI$,Cayman Islands Dollars,2025-01-28 06:00:00.623873,cent,100 CAD,146861.86,$,Canadian Dollars,2025-01-29 14:23:50.320343,cent,100 EUR,97809.2,€,Euro,2025-01-29 14:23:50.320588,cent,100 GBP,81857.61,£,British Pounds,2025-01-29 14:23:50.320769,pence,100 JPY,15805071.28,¥,Japanese Yen,2025-01-29 14:23:50.320945,sen,100 USD,101724.26,$,United States Dollars,2025-01-29 14:23:50.321121,cent,100 AUD,163546.06,$,Australian Dollars,2025-01-29 14:23:50.321297,cent,100 CNY,729474.84,¥,Chinese Yuan Renminbi,2025-01-29 14:23:50.321471,jiao,10 ```

Egge21M commented

2025-03-28 15:46:18 +00:00

(Migrated from github.com)

If you plan to keep a int I suggest that you clarify to specify that it be fractional unit of the currency for a 402 payment required.

There is no such thing in Cashu. Amounts are always integers of the specified unit

> If you plan to keep `a int` I suggest that you clarify to specify that it be `fractional unit` of the currency for a 402 payment required. There is no such thing in Cashu. Amounts are always integers of the specified unit

👍 1

trbouma commented

2025-03-28 17:25:33 +00:00

(Migrated from github.com)

If you plan to keep a int I suggest that you clarify to specify that it be fractional unit of the currency for a 402 payment required.

There is no such thing in Cashu. Amounts are always integers of the specified unit

So, if "usd" can only specify whole dollars?

> > If you plan to keep `a int` I suggest that you clarify to specify that it be `fractional unit` of the currency for a 402 payment required. > > There is no such thing in Cashu. Amounts are always integers of the specified unit So, if "usd" can only specify whole dollars?

Egge21M commented

2025-03-28 17:47:08 +00:00

(Migrated from github.com)

So, if "usd" can only specify whole dollars?

A single unit of "usd" represents a dollar cent. There are no floats in the Cashu protocol.

> So, if "usd" can only specify whole dollars? A single unit of "usd" represents a dollar cent. There are no floats in the Cashu protocol.

trbouma commented

2025-03-28 18:13:35 +00:00

(Migrated from github.com)

So, if "usd" can only specify whole dollars?

A single unit of "usd" represents a dollar cent. There are no floats in the Cashu protocol.

That's ok - if it's clarified in the spec. Currency is usually expressed as a main (base) unit and a fractional unit. I read the spec as the main unit, but it's actually the fractional unit. It wasn't apparent to me. Just wanting to reduce the potential confusion.

FWIW

From wikipedia

Each currency typically has a main currency unit (the dollar, for example, or the euro) and a fractional unit, often defined as 1⁄100 of the main unit: 100 cents = 1 dollar, 100 centimes = 1 franc, 100 pence = 1 pound, although units of 1⁄10 or 1⁄1000 occasionally also occur. Some currencies do not have any smaller units at all, such as the Icelandic króna and the Japanese yen.

> > So, if "usd" can only specify whole dollars? > > A single unit of "usd" represents a dollar cent. There are no floats in the Cashu protocol. That's ok - if it's clarified in the spec. Currency is usually expressed as a main (base) unit and a fractional unit. I read the spec as the main unit, but it's actually the fractional unit. It wasn't apparent to me. Just wanting to reduce the potential confusion. FWIW From wikipedia Each currency typically has a main currency unit (the [dollar](https://en.wikipedia.org/wiki/Dollar), for example, or the [euro](https://en.wikipedia.org/wiki/Euro)) and a fractional unit, often defined as 1⁄100 of the main unit: 100 [cents](https://en.wikipedia.org/wiki/Cent_(currency)) = 1 [dollar](https://en.wikipedia.org/wiki/Dollar), 100 [centimes](https://en.wikipedia.org/wiki/Centime) = 1 [franc](https://en.wikipedia.org/wiki/Franc), 100 pence = 1 [pound](https://en.wikipedia.org/wiki/Pound_sterling), although units of 1⁄10 or 1⁄1000 occasionally also occur. Some currencies do not have any smaller units at all, such as the [Icelandic króna](https://en.wikipedia.org/wiki/Icelandic_kr%C3%B3na) and the [Japanese yen](https://en.wikipedia.org/wiki/Japanese_yen).

Egge21M commented

2025-03-28 19:31:24 +00:00

(Migrated from github.com)

I think this is out of scope for this NUT / PR. Cashu does not dictate anything about what "unit" can be. It can be a currency or something completely different. Also two mints can have key sets for different things that still share a name. The unit and "what it means" is only the mints responsibility and the spec can not specify anything about that.

thesimplekid commented

2025-03-28 22:11:04 +00:00

(Migrated from github.com)

implemented in athenut github.com/thesimplekid/athenut-mint@723f8cd0c8

implemented in athenut https://github.com/thesimplekid/athenut-mint/commit/723f8cd0c8012bedcd6fae7674c5b248b1142dec

🎉 1

Egge21M (Migrated from github.com) reviewed

2025-04-01 05:51:17 +00:00

23.md

Is P2PKOption defined anywhere?

positiveblue commented

2025-04-09 06:11:08 +00:00

(Migrated from github.com)

Bump

I would try to bake the "multiple offer support" in

Bump ``` I would try to bake the "multiple offer support" in ```

gudnuf commented

2025-04-16 16:35:06 +00:00

(Migrated from github.com)

This PR does define the x-cashu behavior which is useful, but I wonder if it deserves a new nut?

Seems like this new nut is unnecessary with the change in #243 that makes the transport field optional. If the transport field in a payment request is undefined then the client can know to respond with payment in band. This PR does define the x-cashu behavior which is useful, but I wonder if it deserves a new nut?

hzrd149 commented

2025-04-16 17:25:20 +00:00

(Migrated from github.com)

Seems like this new nut is unnecessary with the change in https://github.com/cashubtc/nuts/pull/243 that makes the transport field optional. If the transport field in a payment request is undefined then the client can know to respond with payment in band.

It helps to have the HTTP 402 process clearly spelled out in a NUT so that all servers and clients implementing it don't have to worry about 4+ different implementations ( which is usually what happens without clear instructions )

This PR does define the x-cashu behavior which is useful, but I wonder if it deserves a new nut?

I don't know if it needs it own NUT, but it might make NUT-18 more crowded if it was merged into that

> Seems like this new nut is unnecessary with the change in https://github.com/cashubtc/nuts/pull/243 that makes the transport field optional. If the transport field in a payment request is undefined then the client can know to respond with payment in band. It helps to have the HTTP 402 process clearly spelled out in a NUT so that all servers and clients implementing it don't have to worry about 4+ different implementations ( which is usually what happens without clear instructions ) > This PR does define the x-cashu behavior which is useful, but I wonder if it deserves a new nut? I don't know if it needs it own NUT, but it might make NUT-18 more crowded if it was merged into that

👍 1

Egge21M commented

2025-04-17 09:52:25 +00:00

(Migrated from github.com)

I think it is worth keeping this in a separate NUT, as it defines the header structure and protocol (both are clearly not part of NUT-18 scope).

👍 2

hzrd149 commented

2025-04-24 16:20:46 +00:00

(Migrated from github.com)

Created an experimental blossom server using NUT-23 for payments https://github.com/hzrd149/morning-glory
Although its not running anywhere at the moment

Created an experimental blossom server using NUT-23 for payments https://github.com/hzrd149/morning-glory Although its not running anywhere at the moment

lescuer97 (Migrated from github.com) reviewed

2025-05-03 12:08:59 +00:00

23.md

I believe it comes from this pr: https://github.com/cashubtc/nuts/pull/243/files

thesimplekid (Migrated from github.com) reviewed

2025-05-04 06:47:40 +00:00

23.md

We should change this to be a nut10 object like in https://github.com/cashubtc/nuts/pull/248

hzrd149 commented

2025-05-24 17:56:46 +00:00

(Migrated from github.com)

Would it make sense to mention using the Authorization header with a bearer token as an alternative? or switching the X-Cashu header to the Authorization for client -> server requests?

Routstr is using the Authorization header https://docs.routstr.com/api-reference/introduction#authentication

The biggest downside I can see to using the Authorization is that it would prevent clients or servers from using common authentication methods like JWT along side cashu payments. maybe they won't be used together at all but I think its worth considering

Would it make sense to mention using the `Authorization` header with a bearer token as an alternative? or switching the `X-Cashu` header to the `Authorization` for client -> server requests? Routstr is using the `Authorization` header https://docs.routstr.com/api-reference/introduction#authentication The biggest downside I can see to using the `Authorization` is that it would prevent clients or servers from using common authentication methods like JWT along side cashu payments. maybe they won't be used together at all but I think its worth considering

9qeklajc commented

2025-06-08 19:43:17 +00:00

(Migrated from github.com)

Would it make sense to mention using the Authorization header with a bearer token as an alternative? or switching the X-Cashu header to the Authorization for client -> server requests?

Routstr is using the Authorization header https://docs.routstr.com/api-reference/introduction#authentication

The biggest downside I can see to using the Authorization is that it would prevent clients or servers from using common authentication methods like JWT along side cashu payments. maybe they won't be used together at all but I think its worth considering

When I began this project here, I considered separating the Authorization header from the cashu token and came up with this solution. I introduced two distinct headers: X-PAYMENT-SATS for the payment and X-CHANGE-SATS for the change.

I'm considering whether we could use the X-Cashu header for both the payment and the change. Depending on the context, it could be interpreted as follows (if we decide on this approach, we should clarify it in the specification):

Request -> Payment
Response -> Change

I will use this reference as a guide to implement for the client here

> Would it make sense to mention using the `Authorization` header with a bearer token as an alternative? or switching the `X-Cashu` header to the `Authorization` for client -> server requests? > > Routstr is using the `Authorization` header https://docs.routstr.com/api-reference/introduction#authentication > > The biggest downside I can see to using the `Authorization` is that it would prevent clients or servers from using common authentication methods like JWT along side cashu payments. maybe they won't be used together at all but I think its worth considering When I began this project [here](https://github.com/9qeklajc/ecash-402-client?tab=readme-ov-file#example-api-request-with-ecash-payment), I considered separating the Authorization header from the cashu token and came up with [this solution](https://github.com/9qeklajc/ecash-402-client?tab=readme-ov-file#example-api-request-with-ecash-payment). I introduced two distinct headers: X-PAYMENT-SATS for the payment and X-CHANGE-SATS for the change. I'm considering whether we could use the X-Cashu header for both the payment and the change. Depending on the context, it could be interpreted as follows (if we decide on this approach, we should clarify it in the specification): Request -> Payment Response -> Change I will use [this reference](https://github.com/cashubtc/nuts/pull/239#issuecomment-2762693799) as a guide to implement for the client [here](https://github.com/9qeklajc/ecash-402-client?tab=readme-ov-file#example-api-request-with-ecash-payment)

Egge21M commented

2025-06-09 01:29:37 +00:00

(Migrated from github.com)

The biggest downside I can see to using the Authorization is that it would prevent clients or servers from using common authentication methods like JWT along side cashu payments. maybe they won't be used together at all but I think its worth considering

I use both headers simultaneously in npub.cash and I don't think Authorization is the right header for a payment. I don't see any benefit of switching from the X-Cashu header.

> The biggest downside I can see to using the `Authorization` is that it would prevent clients or servers from using common authentication methods like JWT along side cashu payments. maybe they won't be used together at all but I think its worth considering I use both headers simultaneously in npub.cash and I don't think `Authorization` is the right header for a payment. I don't see any benefit of switching from the `X-Cashu` header.

👍 1

thesimplekid (Migrated from github.com) requested changes

2025-06-09 08:54:24 +00:00

23.md

    "nut10": NUT10Option <optional>

```suggestion "nut10": NUT10Option <optional> ```

- `nut10`: The required [NUT-10][10] locking condition

```suggestion - `nut10`: The required [NUT-10][10] locking condition ```

> [!IMPORTANT]
> The transport can be empty! If the transport is empty, we implicitly assume that the payment will be in-band. An example is X-Cashu where the payment is expected in the HTTP header of a request. We can only hope that the protocol you're using has a well-defined transport.

```suggestion > [!IMPORTANT] > The transport can be empty! If the transport is empty, we implicitly assume that the payment will be in-band. An example is X-Cashu where the payment is expected in the HTTP header of a request. We can only hope that the protocol you're using has a well-defined transport. ```