NUT-29: add method field for mint and melt quotes, web socket notifications #378

Open
opened 2026-05-24 07:26:41 +00:00 by ye0man · 3 comments
ye0man commented 2026-05-24 07:26:41 +00:00 (Migrated from github.com)
No description provided.
thesimplekid commented 2026-05-27 13:10:03 +00:00 (Migrated from github.com)

I think this issue is not Nut29, but is related to the to the the NUT04/NUT05 request and response structs not having the method within the struct. This means that the type can only be know by the the shape or the the endpoint that is being used. The shape fails to be a good way to differentiate in the case of the shape being the same for multiple methods, for example onchain, bolt12 and if we add custom methods the shapes are all the same.

This is specifically an issue for websocket notifications where there is not even the endpoint, so the only option is the shape, so since this is not an option wallets must track what methods map to what subscription ids.

So the suggestion is to add the method name to the struct of the Mint/Melt Quote request and response types.

I think this issue is not Nut29, but is related to the to the the NUT04/NUT05 request and response structs not having the method within the struct. This means that the type can only be know by the the shape or the the endpoint that is being used. The shape fails to be a good way to differentiate in the case of the shape being the same for multiple methods, for example onchain, bolt12 and if we add custom methods the shapes are all the same. This is specifically an issue for websocket notifications where there is not even the endpoint, so the only option is the shape, so since this is not an option wallets must track what methods map to what subscription ids. So the suggestion is to add the method name to the struct of the Mint/Melt Quote request and response types.
robwoodgate commented 2026-05-28 11:28:34 +00:00 (Migrated from github.com)

Ok, I understand the issue in context of WS notifications. Though the wallet would have requested a quote ID using a specific method, it then needs to track that method <--> ID mapping so it can figure out how to complete an operation if the update comes via WS.

Ok, I understand the issue in context of WS notifications. Though the wallet would have requested a quote ID using a specific method, it then needs to track that method <--> ID mapping so it can figure out how to complete an operation if the update comes via WS.
thesimplekid commented 2026-05-28 11:48:28 +00:00 (Migrated from github.com)

Though the wallet would have requested a quote ID using a specific method, it then needs to track that method <--> ID mapping so it can figure out how to complete an operation if the update comes via WS.

Yes it is possible to track this, and is what cdk does now. However, I think it is better to make it more explicit what method the struct is for within the struct itself.

> Though the wallet would have requested a quote ID using a specific method, it then needs to track that method <--> ID mapping so it can figure out how to complete an operation if the update comes via WS. Yes it is possible to track this, and is what cdk does now. However, I think it is better to make it more explicit what method the struct is for within the struct itself.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
forgejo-admin/nuts#378
No description provided.