• daviddias
        not every cbor parser, if it doesn't have the knowledge of the tag
      • nicolagreco
        in between ipfs dag get <cid> | cbor | cbor-to-json | json -someKey
      • daviddias
        a generic cbor parser will just go 'I dunno what this is'
      • kythyria[m]
        And emit a string, yes?
      • nicolagreco
        oh I see, so unknown tags can't be used? strange
      • djo[m] has left the channel
      • kythyria[m]
        They can be used but IIRC will be ignored.
      • nicolagreco
        but at that stage we "could", not saying that that is a great idea
      • we could make a special cbor parser
      • ipld-cbor so that we achieve what you wanted to achieve via command lien
      • kythyria[m]
        So if you have the cbor for `{"foo": <tag-ipld-path> "/foo/bar"}` a generic reader will, AFAIK, treat that as `{"foo": "/foo/bar"}`
      • nicolagreco
        a generic cbor parser would still continue to parse, right?
      • alright, but a good parser should notify the developer that there is a tag there
      • otherwise what are tags made for?
      • if that is not the case ^, then we need better cbor parsers
      • kythyria[m]
        Yeh. A CBOR-specific API should still show the tag, but converting to json will mangle the data.
      • nicolagreco
        I see what you are saying now
      • so let me reframe this conversation so we have a common vocabulary
      • there is an ipld object that can have a cbor and a json representation
      • in way number one, the cbor and the json representation are identical
      • in way number two, they are different
      • but they are still the same ipld object
      • regardless of whether they have a '/' or not
      • the only issue in way number two, is that converting across formats needs knowledge of IPLD
      • which might be difficult for a developer that is not using an IPLD library to parse and traverse data
      • jkilpatr has quit
      • or to create and modify json or cbor objects in their raw format
      • I would like to think about all the ipld representations as something that are only touchable via an ipld library
      • since some future formats might be impossible to edit in their raw representation
      • or in some cases it would not make sense to have a `/` extra key/value
      • lidel has quit
      • daviddias
        "nicolagreco> oh I see, so unknown tags can't be used? strange" Not necessarily strange. If you require a schema to parse something, then something can't parse it without the schema.
      • nicolagreco
        Ok, here the question is: do we want anyone to read raw cbor or only clients that know that that cbor should be read in the ipld way
      • daviddias
        We can definitely create the dag-cbor parser for all the languages and tell people 'use these only'
      • but that is added complexity, and that is what I'm trying to surface :)
      • nicolagreco
        yes yes, it is clear now
      • I needed to distill what is the fundamental question
      • does what I ask above make sense?