Has anyone had any progress in decoding the crazy cbor that is sent/returned from canisters when using xhr requests? This seems like a good target for a react tools style plug in that would allow you to ‘pretty print’ the cbor. I guess you need to know the candid interface to decode it? Any suggestions for tools to use? I’m guessing JSON was just too straightforward and widely accepted to be considered cool?
I’m sure there are performance benefits, but man…what a pain. Let’s fix it! 
1 Like
Libraries: CBOR — Concise Binary Object Representation | Implementations
Online tool: http://cbor.me/
1 Like
Trying to figure out a CBOR-decoded response (to a “request-status” call) below.
From the IC spec document, I understand the sig is a certification of IC state, but what about the actual payload (“tree”), how do I map it the actual state-tree?
{ ‘certificate’: { ‘signature’: 'hexb aa ac 9a 1d 69 6e e3 9b 1a e4 b1 01 7e ’
'bf 93 19 43 c8 1b b3 fe 68 b5 dd 06 15 77 f1 ’
'0f f8 dc f7 65 b9 7a 8d 9b 63 30 95 93 76 c7 ’
‘d9 71 9b 37 89’,
‘tree’: [ ‘int 1’,
[‘int 4’, ‘simp 15’],
[ ‘int 1’,
[‘int 4’, ‘int 7’],
[ ‘int 2’,
‘hexb 74 69 6d 65’,
[ ‘int 3’,
‘hexb cc a7 92 de b8 ae 83 c2 16’]]]]}}
I’ve tried the cbor.me tool before. I have no idea what to paste where to translate it. Take this response from dscvr.one:
Where do I paste that response? If I put it on the left of cbor.me I get
ED # primitive(13)
##### 1 unused byte after the end of the data item:
CA
If I put it on the right I get
simple(13)
What do I need to paste where and what boxes need to be checked to convert this notation to some kind of readable structure?
If you use nix, you can install some convenience tools with
$ nix-env -i cbor-diag
But I think they don’t do much more than cbor.me.
So if I want to convert the response of a query to a canister to json, what arguments do I give? Do I have to convert the text in the response window of chrome inspector to binary? And then pass it to this tool?
The response to a query is typically a Candid value, not a CBOR values. You only need to worry about CBOR if you are writing your own agent (library interacting with the IC), or are debugging things related to that low level.
But for low-level requests, you can use these CLI tools:
$ GET https://ic0.app/api/v2/status|file -
/dev/stdin: Concise Binary Object Representation (CBOR) container (array) (map)
$ GET https://ic0.app/api/v2/status|cbor2yaml.rb
--- !ruby/struct:CBOR::Tagged
tag: 55799
value:
ic_api_version: 0.17.0
root_key: !binary |-
MIGCMB0GDSsGAQQBgtx8BQMBAgEGDCsGAQQBgtx8BQMCAQNhAIFMDm7HH6tYOwi9gTc8JVw8NxsuhIY8mKTx4It0I10U+12cDNVG2WhfkToMCyzFNBWDv0tDkuRn25bWW5u0y3FxEvhHLg1aTRRQX/10hLASkQkcX4e5iINGP5gJGguqrg==
impl_version: ca35377220efd5efb1f5944e34c4d6caf1aff2df
impl_hash: ebb16175fd93b21e93a79a35935cc11eb1965d4fe4b8d349a59c394ea555d1a2
1 Like
Thank you! Very descriptive. If the response to a query is typically a candid value, why can’t I read it? See the image above. How do I convert that garbled text into a candid object?
Ah, the HTTP response is indeed CBOR, but it carries, in the arg field, the response from the canister (which is either a reject message, or a reply, which itself is typically Candid encoded). Different layers of abstraction; a bit like IP/TCP/HTTP/JSON).
So that response should work with cbor.me. But the problem you are facing is that current browser developer tools are surprisingly bad at this when the response is binary. I would expect that UI to have a checkbox to show the response in hex (which you could then paste into cbor.me).
If I work locally, without HTTPS, I sometimes use wireshark to sniff the HTTP exchange and copy the HTTP payload there.
If anyone has a quick overview for how they make a valid CBOR / Candid object from the junk in chrome devtools 
I’m just still confused why they didn’t use good old-fashioned json. Sometimes it seems like the most obtuse tool was chosen on purpose. How many devs have tried to inspect the messages sent on an IC app and just peace outed? 
8 Likes
I guess when you’re replicating stuff a whole bunch of times as you do on a blockchain, the concision of CBOR starts to make more sense as the default message format on the IC??? Not to understate your point… the developer experience is really bad right now. Seems not so hard to add application/cbor interpreter to devtools, technically speaking–I have no idea what that process is like. On top of that, it sounds like we need a Candid interpreter in there. 
I guess you could also do something like make canisters translate cbor/candid to json for http requests. Honestly not sure which approach is better.
Life would be SO MUCH easier with a fix in place.
Sounds like a good bounty opportunity. Hmmm…
3 Likes
It’s a killer bounty idea. Get a grant and make it happen. I’m up for a collab.
I don’t think there’s anything that we can do from the agent-js side to clean up the default network tab preview, but it would be really nice if there was. If there’s any requirement to hook into agent-js from a devtools extension, I’m happy to accommodate it
We probably have 20ICP we can put behind it from ICDevs right away. We just need to write up the simplest path forward. I’m guessing it is something along the lines of adding a tab to the dev tools via a plug-in that looks for cbor and decodes it and then further decodes any candid it finds?
1 Like
That makes a lot of sense. I went straight to patching devtools core 
. I’ve yet to parse the output even manually, but getting that down then building a little devtools extension seems like the shortest critical path.
Dove into this a bit today. What we’re getting back from a canister is b64 encoded byte array. Getting that to play nicely with cbor.me was a matter of hex encoding it. Now I just need to throw Candid decoding in there. Am I crazy, or is it only possible encode/decode Candid if you have type data? agent-js seems to be providing types as well as args for each encode/decode event. If so, I suppose the extension would have to provide a way to map an interface onto a canister in order to function.