raw token converters #207
raw token converters #207
Conversation
src/utils.ts
Outdated
| @@ -521,3 +531,16 @@ export function hasValidDleq(proof: Proof, keyset: MintKeys): boolean { | |||
|
|
|||
| return true; | |||
| } | |||
|
|
|||
| export function tokenToRawToken(token: string | Token): Uint8Array { | |||
There was a problem hiding this comment.
This feels like bait :P
I think we should come up with a proper name for this. We call the the serialised version TokenV4 and the object notation TokenV4Template, so maybe this can be TokenV4Binary?
There was a problem hiding this comment.
agree xD sorry for the bad naming. Yes TokenV4Binary is good
src/utils.ts
Outdated
| @@ -521,3 +531,16 @@ export function hasValidDleq(proof: Proof, keyset: MintKeys): boolean { | |||
|
|
|||
| return true; | |||
| } | |||
|
|
|||
| export function tokenToRawToken(token: string | Token): Uint8Array { | |||
| if (typeof token === 'string') { | |||
There was a problem hiding this comment.
I would prefer this to only accept token and outsource conversion to the implementer. I think the readability improves if functions only do one (or close to one) thing.
There was a problem hiding this comment.
Yeah that makes sense to me. I will change it accordingly
|
@gandlafbtc is there a spec for this? It seems to me like not having any versioning might be a mistake here. |
No spec for this afaik but it should be mentioned in NUT-00 that the CBOR structure can be exported without base64 when binary transport is possible. We do however need to come up with a magic byte prefix and a version like "cashuB" if we do that. |
|
yeah, the structure is the "version 4" structure. but I agree with what @callebtc said. maybe just a version field in the CBOR structure? |
Take a look at this: cashubtc/nuts#199 |
Yes, let's agree on binary format in described cashubtc/nuts#199 first, merge that PR and only afterwards merge this PR |
|
I have adjusted this to match the newly merged binary token spec. Tests are still missing though |
|
The code only supports V4 Binary tokens. Should we add the V3 binary tokens support to cashu-ts or should we remove V3 binary tokens from the spec? I am in favor for the latter, but no strong opinions here. |
Good point... Adding them would be easy, but adding them to the spec in the first place was probably a mistake. Edit: It would make sense to remove them to signal that this format requires modern keyset IDs, just like the regular v4 encoding. |
|
I removed the reference to V4 completely now. I also adjusted the tests and exports. This is good to go i'd say |
Fixes: exposing functions for raw token format
Description
Some transport methods (like nfc) require the lowest amount of data overhead possible. This PR addresses that by externalizing the raw token format (CBOR)
Changes
PR Tasks
npm run test--> no failing unit testsnpm run format