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: https://github.com/ipld/specs/issues/25
  • Write serializer/deserializer modules
  • [ ] IPLDDagStore (rename needed)
  • [ ] Resolver
  • Make it into its own module: https://github.com/ipld/specs/issues/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).