Should the JSON represenetation of CID always be formatted as links. about go-cid HOT 6 OPEN

Really, this is the correct format for DagJSON (that is the JSON IPLD format). Unfortunately, our APIs don't use DagJSON (they should but it's hard to fix that now).

We did the {"/": ...} dance to add a new "primitive" type (the CID) to JSON.

In practice, this allows us to write:

type Person struct {
  name string
  friends map[string]cid.Cid
}

And have json.Marshal(somePerson) spit out valid IPLD.

from go-cid.

@Stebalien that may be true, but now that we can put strings in maps how will map[cid.Cid]string serialize since the key is a JSON object and not a string?

from go-cid.

It won't. That's not valid DagJSON. It could serialize to CBOR (in theory) but we currently restrict map keys to be strings (IIRC, this is a hold-over from the days when we wanted all map keys to be valid path components).

from go-cid.

Right my point is with the current serialization of a CID a map[cid.Cid]string won't serialize to valid JSON. This could be a problem.....

EDIT: I didn't actually try this so let em write some quick test cases first....

from go-cid.

So after testing and a little more research it seams map[cid.Cid]string won't serialize anyway. To fix this we would need to implement the encoding.TextMarshaler and encoding.TextUnmarshaler interface which just convert the Cid to string without a path comment.

from go-cid.

I was going to open an issue to discuss that { "/" : <cid> } is quite weird and I think it's inconsistent in some places in the go-ipfs API how CIDs are presented. While correct in the IPLD context, it difficults using CIDs in non-IPLD contexts. CIDs are the core identifier for IPLD, but must they have a IPLD-based JSON output?

Note how this requires that every language implements additional json handling for CIDs just because it does not come as a simple string that can be thrown to Decode(). It just becomes harder to work with CIDs and it's not obvious why things are as they are.

Would having a global switch (variable) that just outputs them as a string be an option? It's a bad solution, but I can't think of anything non-breaking and would help cluster keep API compatibility if we let Cids marshal themselves to JSON in the future.

from go-cid.