Implementation: Tracking implementation effort for IPLD v1

[nicola]

According to our conversation (meeting-notes/2016-09-19-ipld.md#layers), here are the following layers we have agreed on having:

• Layers
  • Blobstore
  • Format-specific Serializers/Deserializers
    • Separate IPLD from CBOR: Implementation: separate IPLD from CBOR #25
    • Write serializer/deserializer modules
  • IPLDDagStore (rename needed)
  • Resolver
    • Make it into its own module: Implementation: Make resolver into its own module #26
  • IPLD Service
• Interop
  • Understand and discuss with friends at Dat, Ethereum & co on how to make this effort work or be supported in their systems
  • ...

Please, check as soon as the work is done (also, link issues and I will add them in here)

---

cc @dignifiedquire @flyingzumwalt (also, is this the right place for implementation conversations? should we use ipld/ipld instead?)

[Stebalien]

I'll let someone else create the interoperability issue (so that they can edit it) but I'll leave some comments here. Basically, I think we actually have pretty much everything in place but are missing a few components to connect everything together.

1. Some blobstores (git, dat) may only support certain formats (multicodecs). There should be a way for the blobstore to negotiate supported/preferred formats with the IPLDDagStore.
2. It would be nice to be able to manually import/export a blob through the IPLDDagStore. Basically, import: (blob, spec) -> CID where spec specifies the multicodec and hash-fn-code and export: (CID) -> blob (basically just calls get on the blobstore).

dat would simply be a blobstore that:

1. Only accepts blobs where the CID matches the dat spec.
2. Strips the metadata from the key (leaving only the hash) when the IPLDDagStore calls put(key, value).