Considering renaming to just js-ipld

[daviddias]

This module was named ipld-resolver because it was designed to the mother of all local resolvers (dag-pb, dag-cbor, eth-*, etc) and act as a facade for a future IPLD cli (for people wanting to play with IPLD in the terminal), an IPLD playground (a project @nicola and @victorbjelkholm were working on) and finally, by js-ipfs witht he DAG API.

It turned out that the DAG API became pretty much the API that this module implements directly, the IPLD cli is a bit dormant and we definitely have to wake up the IPLD Playground.

What I'm thinking, to reduce fragmentation and make it more obvious that "hey world, this is your entry point to IPLD if you want to play with IPLD" is to rename this module to js-ipld and add the CLI feature here, possibly following this feature ipfs/notes#194

This would also encourage us to make this module work very much standalone (spawning its own in memory or local repo) so that users can play with IPLD at will without having to boot a full node.

Thoughts?

[nicola]

+1

[victorb]

In the end, we'll have three "entrypoints" to using IPLD:

• CLI
• Playground
• js-ipfs DAG API

To avoid bundling all of them together, it makes sense to rename this module to js-ipld, and create js-ipld-{cli, playground} separately, as they conceptually only share IPLD but not functionality.

The responsibility of being standalone would belong to itself (the tool), so the CLI would know how to maintain the memory/local repository, while the core (js-ipld) doesn't really care about that, since for js-ipfs it doesn't really matter

[daviddias]

@vmx more context on #110 here

[daviddias]

last step #116 #117