RFC: OBJECT API should accept CIDv1

[lidel]

OBJECT API SPEC Status

According to OBJECT SPEC v0.86.0 the following API functions still expect raw multihash (CIDv0) as input:

• object.get
• object.data
• object.stat 💢
• object.rmLink 💢
• object.addLink 💢
• object.appendData 💢
• object.setData 💢
• object.links 💢

CIDv1 Implementation Status

• 🔴 js-ipfs-api follows the spec (I checked APIs indicated with 💢) and returns Error: not valid multihash if CIDv1 is passed. This was originally reported by user in ipfs/ipfs-companion#628 (comment).
• 🔴 js-ipfs v0.33.1 - I did not check all OBJECT APIs, but seems to have similar issues: jsipfs object stat bafybeie5gq4jxvzmsym6hjlwxej4rwdoxt7wadqvmmwbqi7r27fclha2va → not valid multihash
• 💚 go-ipfs v0.4.18 - implementation of OBJECT API accepts CIDv1 and works just fine (at least ipfs object stat, did not test the rest)

Change Proposal: Add Support for CIDv1

Given that we are moving to cidv1b32 as a new default, switching API/SPEC to accept CIDv1 would make more sense going forward.

Proposed steps:

1. Change OBJECT spec to accept cid argument instead of multihash
2. Update js-ipfs(-api) to follow new spec and support CIDv1 (eg. refactor use of clean-multihash to clean-cid)
3. Add interop tests with CIDv1 for OBJECT API

Y/n?

[alanshaw]

Supporting this should be pretty easy. The CID is passed to IPLD so it's just validation in the CLI, HTTP and core APIs that is restricting it.

The biggest issue for JS right now is that it won't be able to retrieve the data if you give it a CIDv1 that was added as CIDv0, however, this will be addressed in 0.34.

[daviddias]

@alanshaw you already shipped this, right?

[alanshaw]

Yes! I just checked ALL of the object API methods both with and without the daemon (so via the HTTP API as well as core) and they all work as expected :D

[achingbrain]

This has been shipped so I'm closing this issue - please open a new one on ipfs/js-ipfs if there's anything else left to do.