NUT-18: Add optional nut10 options and transport field #248

2025-04-15T18:27:07Z

gudnuf commented

2025-04-15 18:27:07 +00:00

(Migrated from github.com)

An alternative update to NUT-18 that would allow for payment requests to define any spending condition supported by NUT-10

CDK https://github.com/cashubtc/cdk/pull/744
Nutshell
cashu-ts https://github.com/cashubtc/cashu-ts/pull/285
nutmix

An alternative update to NUT-18 that would allow for payment requests to define any spending condition supported by NUT-10 - [x] CDK https://github.com/cashubtc/cdk/pull/744 - [ ] Nutshell - [x] cashu-ts https://github.com/cashubtc/cashu-ts/pull/285 - [ ] nutmix

callebtc (Migrated from github.com) reviewed

2025-04-15 18:27:07 +00:00

Egge21M (Migrated from github.com) approved these changes

2025-04-17 10:00:05 +00:00

18.md

					
				@ -38,11 +39,32 @@ Here, the fields are

				- `m`: A set of mints from which the payment is requested

nit: probably out of scope. This is part of NUT-10

a1denvalu3 (Migrated from github.com) reviewed

2025-04-17 15:01:13 +00:00

18.md

					
				@ -38,11 +39,32 @@ Here, the fields are

				- `m`: A set of mints from which the payment is requested

@gudnuf

thesimplekid (Migrated from github.com) approved these changes

2025-05-04 06:44:31 +00:00

thesimplekid commented

2025-05-04 10:24:20 +00:00

(Migrated from github.com)

PR for CDK https://github.com/cashubtc/cdk/pull/744

KnowWhoami (Migrated from github.com) reviewed

2025-05-12 15:55:18 +00:00

18.md

We can only hope that the protocol you're using has a well-defined transport.

Why is the Transport field optional?
While this may provides flexibility to downstream users to implement thier own Transportation mechanism , it could raise security issues etc in their protocols ,if the custom implementation is poorly designed or lacks standarization.

Would it better to explicitly define the Transport field or at least , specify a recommended / standarized way as default transport method to mitigate such risks??

> We can only hope that the protocol you're using has a well-defined transport. Why is the `Transport` field optional? While this may provides flexibility to downstream users to implement thier own Transportation mechanism , it could raise security issues etc in their protocols ,if the custom implementation is poorly designed or lacks standarization. Would it better to explicitly define the `Transport` field or at least , specify a recommended / standarized way as default transport method to mitigate such risks??

gudnuf (Migrated from github.com) reviewed

2025-05-13 16:49:41 +00:00

18.md

Prior to this PR, Transport was required. Having no defined transport makes sense for use cases like NFC or L402 where we are expected to respond with a token via the same transport that the request was received. For example, with L402 we get a request in the X-cashu header and then our response includes a token in the X-cashu header.

Would it better to explicitly define the Transport field or at least , specify a recommended / standarized way as default transport method to mitigate such risks??

We don't know what people will build so these recommended transports wouldn't make sense in all cases

Prior to this PR, `Transport` was required. Having no defined transport makes sense for use cases like NFC or L402 where we are expected to respond with a token via the same transport that the request was received. For example, with L402 we get a request in the X-cashu header and then our response includes a token in the X-cashu header. > Would it better to explicitly define the Transport field or at least , specify a recommended / standarized way as default transport method to mitigate such risks?? We don't know what people will build so these recommended transports wouldn't make sense in all cases