Should the JSON represenetation of CID always be formatted as links.

[kevina]

My understanding is that the idea behind {"/": <cid-string>} is when Cid are represented as links. Should they always be serialized like this. In many cases a Cid acts more as an identifier than a link.

I see it just adding additional overhead to the JSON stream, espacally when returning a list of CIDs

Also it seams that even the idea of encoding them this was in conversational, at least based on @Stebalien comments in ipld/specs#70 when he said:

I'm really not happy baking this into IPLD. {'/': ...} was a hack to get JSON working.

This will need some strong arguments/motivations.

and

this was never intended to be the canonical representation. It was a hack to get JSON working.

[Stebalien]

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.

[kevina]

@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?

[Stebalien]

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).

[kevina]

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.

[hsanjuan]

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.