feat: cid base option

[alanshaw]

Implements an option for the CLI, HTTP API and core (where appropriate) that will allow the user to pick the multibase encoding for any CIDs that are returned as strings.

NOTE Using the CID base option in bitswap, dag and object APIs WILL NOT auto upgrade your CID to v1 if it is a v0 CID and WILL NOT apply the encoding you specified. This is because these APIs return IPLD objects with links and changing the version of the links would result in a different hash for the node if you were to re-add it. Also, the CID you used to retrieve the node wouldn't actually refer to the node you got back any longer. Read this for further context.

This PR adds a --cid-base option to the following CLI commands:

• jsipfs bitswap stat
• jsipfs bitswap unwant
• jsipfs bitswap wantlist
• jsipfs block put
• jsipfs block stat
• jsipfs add
• jsipfs ls
• jsipfs object get
• jsipfs object links
• jsipfs object new
• jsipfs object patch add-link
• jsipfs object patch append-data
• jsipfs object patch rm-link
• jsipfs object patch set-data
• jsipfs object put
• jsipfs object stat
• jsipfs pin add
• jsipfs pin ls
• jsipfs pin rm
• jsipfs resolve

Note: these two MFS commands already implement the --cid-base option:

• jsipfs files ls
• jsipfs files stat

It also adds ?cid-base= query option to the following HTTP endpoints:

• /api/v0/bitswap/wantlist
• /api/v0/bitswap/stat
• /api/v0/bitswap/unwant
• /api/v0/block/put
• /api/v0/block/stat
• /api/v0/add
• /api/v0/ls
• /api/v0/object/new
• /api/v0/object/get
• /api/v0/object/put
• /api/v0/object/stat
• /api/v0/object/links
• /api/v0/object/patch/append-data
• /api/v0/object/patch/set-data
• /api/v0/object/patch/add-link
• /api/v0/object/patch/rm-link
• /api/v0/pin/ls
• /api/v0/pin/add
• /api/v0/pin/rm
• /api/v0/resolve

It adds a cidBase option to the following core functions:

• resolve

---

• depends on test: cidBase option in resolve ipfs-inactive/interface-js-ipfs-core#396
• depends on feat: add cidBase option to resolve ipfs-inactive/js-ipfs-http-client#893

[kevina]

P.R. for go-ipfs: ipfs/kubo#5464. Not that for many commands I did it the Cid base conversion client-side when possible.

I agree that for resolve it should be done on the server as the result is a path and not a CID.

[daviddias]

Will this PR also default to base32 or is that a separate PR?

[alanshaw]

Will this PR also default to base32 or is that a separate PR?

@diasdavid that a separate PR

TODO:

• Add inject tests for every changed HTTP endpoint (for cid-base querystring)
• [ ] Add tests to interface-ipfs-core (for core cidBase option) not in core, hopefully this instead: RFC: Do not return string CIDs from core ipfs-inactive/interface-js-ipfs-core#394

[hugomrdias]

LGTM

[kevina]

@alanshaw, I am not sure how high of a priority staying consist with go-ipfs is. If it is a high priority please note that @Stebalien has not signed off yet on how to handle --cid-base on the go-ipfs side, so it is unclear if we will end up supporting cid-base for HTTP requests or the exact semantics we will end up using.

[alanshaw]

@Stebalien can we get a firm decision on whether go-ipfs will support ?cid-base query string argument in the HTTP API as this PR is ready to merge (pending a rebase) and I had planned to include this in the 0.34 release 🔜

Thank you 😄!

---

For context: ipfs/kubo#5777 (comment)