8000 IPLD preparations · Issue #158 · mediachain/mediachain · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
IPLD preparations #158
Open
Open
@yusefnapora

Description

@yusefnapora

I did some reading through the updated ipld spec this morning, as well as the js-ipld implementation.

The biggest breaking change from our perspective is that the @link tag in the json representation has been replaced with /, and "link objects" are now only allowed to have a single key. So a link would now look like e.g.:

{"artist": {"/": "QmF00..."}}

Link properties are now siblings of the "link object" instead of being contained inside it, e.g.:

{
  "thing_with_properties": {
    "prop": "value",
    "link": {"/": "QmF00..."}
  }
}

Since we're not using link properties that seems like it shouldn't affect us, but i'm a bit confused by Link Properties Convention section. It's not clear how to distinguish "pseudo link objects" from plain objects that happen to contain links, which has implications for path resolution.

For example, if we have:

{
  type: "artefact",
  meta: {
    data: {
      title: "Hello world",
      artist: {"/": "Qm123"}
    }
  }
}

Would the path /ipfs/<hash-of-that-object>/meta/data just assume that we were trying to attach link properties to the artist link and replace the value of data with the contents of the artist link? It would be good to get clarification on how path resolution works with these "pseudo link objects" before we dive in. The examples all use the key link for the "real link", but it's not at all clear whether that key is "special" when resolving paths.

The canonical cbor representation hasn't changed much, but it does require the use of cbor tags, which we aren't yet using. The spec still lists "register tag with IANA" as a TODO, but in the js implementation they're using 258 as the tag, so it's probably safe to use that. Our cbor serialization code will need to be updated to use link tags instead of writing out cbor maps.

So, here's some things to do:

  • resolve ambiguity about link properties and path resolution
  • update cbor serialization code to use tags instead of link maps (needs client-side support as well)
  • experiment with js-ipld implementation
    • see if we can put our raw cbor bytes into ipfs and resolve with js-ipld-cli

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0