Improve toJSON of the CID

[Gozala]

At the moment toJSON returns following fields

https://github.com/multiformats/js-multiformats/blob/master/src/cid.js#L202-L208

Last one is Uint8Array, so when you run JSON.stringify over object containing CID it gets mangled into unreadable mess because bytes are turned into object with each byte in own offset property.

Can we please either do something more useful in toJSON or drop that method entirely so that replacer function passed to JSON.stringify can handle the substitution, which currently does not happen because toJSON() is runs before replacer.

[Gozala]

I would personally suggest to update toJSON as follows so it follows DAG-JSON Link representation

 toJSON () {
    return {
      '/': toString()
    }
}

[RangerMauve]

I'm into returning the dag-json representation. 👍 Also @warpfork has been thinking about JSON IPLD more lately, not just with CIDs but also representing bytes.

[Gozala]

I'm into returning the dag-json representation. 👍 Also @warpfork has been thinking about JSON IPLD more lately, not just with CIDs but also representing bytes.

You mean differently from https://ipld.io/specs/codecs/dag-json/spec/#bytes ?

[Gozala]

@rvagg @achingbrain if you're onboard with this I can work on a PR

[RangerMauve]

I think this'd be a breaking change? I'm not sure if there are existing users of this functionality so it'd be good to look into that first before adding it in.

[Gozala]

I think this'd be a breaking change? I'm not sure if there are existing users of this functionality so it'd be good to look into that first before adding it in.

It would be a breaking change, however I'm not sure where to look for the potential users of this API. I also suspect that toJSON got broken unintentionally somewhere down the line as I'm pretty user it did not used to contain Uint8Array serialized as an object.

[Gozala]

We could also just do this for Link and leave CID alone, but then again I think it is a problem that JSON.stringify produces a mess with CIDs and that problem would persist if we choose to leave CID alone.

[RangerMauve]

I'm personally not scared of breaking changes when it's clear what has broken. Especially since this isn't a major API change. Just wondering if there are big projects we should loop in first.

I think DagHaus is doing a lot with JS-IPLD right now so you'd be most likely to see this.