-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add Ipld de/encoding for CACAOs #7
Conversation
Looks good... I confirm the test fails, with the following:
... which is strange because the linked test in Ceramic's implementation includes an "aud" payload value. But I didn't try to check that by decoding the binary data. Another possible test case may be the one in the CACAO CAIP: https://github.com/ChainAgnostic/CAIPs/blob/8fdb5bfd1bdf15c9daf8aacfbcc423533764dfe9/CAIPs/caip-draft_cacao.md#test-cases |
- Add default attribute for optional fields - Add CACAOIpld struct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test decoding from CBOR passes in #12. Round-trip encode/decode succeeds in #13 (However, the serialization is different from the bytes that the Ceramic test vector uses, as some properties are in a different order; therefore different CIDs result...).
I think maybe the dependency on DagCbor in the types could be reduced by using Codec Decode + Encode instead. But to use CIDs it it looks like we have to pick a serialization. CAIP-74 suggests CBOR, and that is what Ceramic's test case uses, so I think we'll be using DagCbor anyway, although we could allow use of other serializations for the CIDs.
Fix CACAO IPLD/DagCbor test
It would be ideal to have By rearranging the |
Implements
Encode<DagCborCodec>
andDecode<DagCborCodec>
forPayload
andCACAO
, to support encoding cacaos as IPLD blocks. Also adds a test case taken from the ceramic cacao-ts tests (currently fails). Closes #4