NUT-17: `proof_state` command should be specified outside of the methods

gudnuf commented

2025-09-03 19:33:42 +00:00

(Migrated from github.com)

Right now, the NUT-17 info config will look something like:

"nuts": {
    "17": {
      "supported": [
        {
          "method": "bolt11",
          "unit": "sat",
          "commands": [
            "bolt11_mint_quote",
            "bolt11_melt_quote",
            "proof_state"
            ]
        },
      ]
    }
}

where proof_state is defined in the methods and would be repeated for each method.

Instead, NUT-17 should be able to specify generic commands that are not method specific and only list them once.

I imaging something like this:

"nuts": {
  "17": {
    "global_commands": [ "proof_state" ],
    "method_support": [
      {
        "method": "bolt11",
        "unit": "sat", 
        "commands": [
          "bolt11_mint_quote",
          "bolt11_melt_quote"
        ]
      }
    ]
  }
}

Right now, the NUT-17 info config will look something like: ```json "nuts": { "17": { "supported": [ { "method": "bolt11", "unit": "sat", "commands": [ "bolt11_mint_quote", "bolt11_melt_quote", "proof_state" ] }, ] } } ``` where `proof_state` is defined in the methods and would be repeated for each method. Instead, NUT-17 should be able to specify generic commands that are not method specific and only list them once. I imaging something like this: ```json "nuts": { "17": { "global_commands": [ "proof_state" ], "method_support": [ { "method": "bolt11", "unit": "sat", "commands": [ "bolt11_mint_quote", "bolt11_melt_quote" ] } ] } } ```

thesimplekid commented

2025-09-05 14:58:23 +00:00

(Migrated from github.com)

It maybe better to do this as a non breaking change. One way would be that if proof_state is specified in any of the payment method it is supported for all.

gudnuf commented

2025-09-05 16:33:25 +00:00

(Migrated from github.com)

It maybe better to do this as a non breaking change. One way would be that if proof_state is specified in any of the payment method it is supported for all.

what if we start to add other "global commands"?

Another idea I had was keep proof_state in bolt11 for backwards compat and then also start defining these methods outside the methods (although not sure what this would look like so that the json schema can stay compatible)

> It maybe better to do this as a non breaking change. One way would be that if proof_state is specified in any of the payment method it is supported for all. what if we start to add other "global commands"? Another idea I had was keep proof_state in bolt11 for backwards compat and then also start defining these methods outside the methods (although not sure what this would look like so that the json schema can stay compatible)

Egge21M commented

2025-09-08 04:37:05 +00:00

(Migrated from github.com)

I just stumbled upon the same thing. Personally I don't think we need the method field at all, as it's explicitly defined in the command name. So a mint would define a set of commands per unit.

gudnuf commented

2025-09-09 19:20:15 +00:00

(Migrated from github.com)

I just stumbled upon the same thing. Personally I don't think we need the method field at all, as it's explicitly defined in the command name. So a mint would define a set of commands per unit.

Good point, we still need to consider units though. A mint may support sockets for bolt11 sat but not usd because of different backends

> I just stumbled upon the same thing. Personally I don't think we need the method field at all, as it's explicitly defined in the command name. So a mint would define a set of commands per unit. Good point, we still need to consider units though. A mint may support sockets for bolt11 sat but not usd because of different backends

Egge21M commented

2025-09-10 04:27:49 +00:00

(Migrated from github.com)

Good point, we still need to consider units though. A mint may support sockets for bolt11 sat but not usd because of different backends

So something like this? I think CDK and nutshell actually emit WS events based on their internal lifecycle (citation needed, @thesimplekid), rather than a notification from the backend, so it should be backend agnostic. But of course that might not stay that way forever.

"nuts": {
  "17": {
    "supported": [
      {
        "unit": "sat", 
        "commands": [
          "proof_state",
          "bolt11_mint_quote",
          "bolt11_melt_quote"
        ]
      },
      {
        "unit": "usd", 
        "commands": [
          "proof_state",
        ]
      },
    ]
  }
}

> Good point, we still need to consider units though. A mint may support sockets for bolt11 sat but not usd because of different backends So something like this? I think CDK and nutshell actually emit WS events based on their internal lifecycle (citation needed, @thesimplekid), rather than a notification from the backend, so it should be backend agnostic. But of course that might not stay that way forever. ```json "nuts": { "17": { "supported": [ { "unit": "sat", "commands": [ "proof_state", "bolt11_mint_quote", "bolt11_melt_quote" ] }, { "unit": "usd", "commands": [ "proof_state", ] }, ] } } ```

Rows
Columns

NUT-17: proof_state command should be specified outside of the methods #284

NUT-17: `proof_state` command should be specified outside of the methods #284