feat(nut04/05): add method_name to [Mint|Melt]MethodSetting#374
feat(nut04/05): add method_name to [Mint|Melt]MethodSetting#374robwoodgate wants to merge 6 commits into
Conversation
|
Does it make sense to add localization here or is that too much? If wallets have language configuration we could pick the relevant one for the user. |
I think too much for an info setting - could run to hundreds of entries. Wallet should make a policy decision to translate / ignore / decide their own names. |
|
I do not think we should localization for the reason Rob stated. However, should we give each method specified in the nut a name (bolt11, bolt12, onchain) so that mints all use the same one and then wallets can display this however they want. I think it would be confusing if cdk names bolt11 "lighting" for example and nutshell calls it "bolt11", wallets would then have to map these two to the same thing. |
i'm thinking we can do: Bolt 11 -> Lightning so cdk and nutshell are compliant to these. |
Why not just bolt11, bolt12, and onchain, wallets can decide to call it something else on the user facing side if they want but don't think we need to add other naming to the spec? |
that works also, just thought we wanted something extra. |
Yes - wallets need predictable strings for translation, but rather than update all the first class nut methods (23/25/30), I added a one liner default rule. |
|
While we are here, anticipating custom methods, we should specify the allowed characters for Cashu-TS only allows "a-z0-9-_" (base64url safe), so I used that as the template. |
# NUT cashubtc/nuts#374 Fiollows on from PR #672 ## Summary When a mint omits `method_name` (null or absent) in its NUT-04/05 method settings, derive a human-readable default from `method`: replace `_`/`-` with spaces and title-case each word (`bolt11` → `Bolt11`, `apple-pay` → `Apple Pay`). Previously such entries were coerced to `null`. `MintInfo.normalizeSwapMethods` now populates `method_name` during normalization, so consumers reading the normalized response get a usable name for every well-formed method. Malformed entries (missing/empty/non-string `method`) still resolve to `null` rather than producing a bogus name. ## Motivation cashubtc/nuts#374 defines a deterministic fallback for `method_name` when unspecified, letting wallets rely on predictable strings instead of requiring every mint to name each method explicitly.
5 participants
This PR adds an optional
method_nameparam to the NUT-04MintMethodSetting, and NUT-05MeltMethodSetting.The motivation is to make it easy for wallets to support custom payment methods in their UI.