multiformats / js-cid Goto Github PK

View Code? Open in Web Editor NEW

98.0 27.0 39.0 1.55 MB

CID implementation in JavaScript

License: MIT License

JavaScript 100.00%

cid javascript ipld

js-cid's Introduction

⛔️ DEPRECATED: This module has been superseded by the multiformats module

js-cid

CID implementation in JavaScript.

Lead Maintainer

Volker Mische

Install
Usage
API
Contribute
License

Install

In Node.js through npm

$ npm install --save cids

Browser: Browserify, Webpack, other bundlers

The code published to npm that gets loaded on require is in fact an ES5 transpiled version with the right shims added. This means that you can require it and use with your favourite bundler without having to adjust asset management process.

const CID = require('cids')

In the Browser through `<script>` tag

Loading this module through a script tag will make the Cids obj available in the global namespace.

<script src="https://unpkg.com/cids/dist/index.min.js"></script>
<!-- OR -->
<script src="https://unpkg.com/cids/dist/index.js"></script>

Usage

You can create an instance from a CID string or CID Uint8Array

const CID = require('cids')

const cid = new CID('bafybeig6xv5nwphfmvcnektpnojts33jqcuam7bmye2pb54adnrtccjlsu')

cid.version       // 1
cid.codec         // 'dag-pb'
cid.code          // 112
cid.multibaseName // 'base32'
cid.toString()
// 'bafybeig6xv5nwphfmvcnektpnojts33jqcuam7bmye2pb54adnrtccjlsu'

or by specifying the cid version, multicodec name and multihash:

const CID = require('cids')
const multihashing = require('multihashing-async')
const bytes = new TextEncoder('utf8').encode('OMG!')

const hash = await multihashing(bytes, 'sha2-256')
const cid = new CID(1, 'dag-pb', hash)
console.log(cid.toString())
// bafybeig6xv5nwphfmvcnektpnojts33jqcuam7bmye2pb54adnrtccjlsu

The multicodec integer code can also be used to create a new CID:

const cid = new CID(1, 112, hash)
console.log(cid.toString())
// bafybeig6xv5nwphfmvcnektpnojts33jqcuam7bmye2pb54adnrtccjlsu

The string form of v1 CIDs defaults to base32 encoding (v0 CIDs are always base58btc encoded). When creating a new instance you can optionally specify the default multibase to use when calling toBaseEncodedString() or toString()

const cid = new CID(1, 'raw', hash, 'base64')
console.log(cid.toString())
// mAXASIN69ets85WVE0ipva5M5b2mAqAZ8LME08PeAG2MxCSuV

If you construct an instance from a valid CID string, the base you provided will be preserved as the default.

// e.g. a base64url encoded CID
const cid = new CID('uAXASIHJSUj5lkfuP5VPWf_VahvhARLRqPkF24QxY-lKaSqvV')
cid.toString()
// uAXASIHJSUj5lkfuP5VPWf_VahvhARLRqPkF24QxY-lKaSqvV

API

CID.isCID(cid)

Returns true if object is a valid CID instance, false if not valid.

It's important to use this method rather than instanceof checks in order to handle CID objects from different versions of this module.

CID.validateCID(cid)

Validates the different components (version, codec, multihash, multibaseName) of the CID instance. Throws an Error if not valid.

new CID(version, codec, multihash, [multibaseName])

version must be either 0 or 1.

codec must be a string of a valid registered codec.

multihash must be a Uint8Array instance of a valid multihash.

multibaseName optional string. Must be a valid multibase name. Default is base58btc for v0 CIDs or base32 for v1 CIDs.

new CID(baseEncodedString)

Additionally, you can instantiate an instance from a base encoded string.

new CID(Uint8Array)

Additionally, you can instantiate an instance from a Uint8Array.

cid.codec

Property containing the string identifier of the codec.

cid.code

Property containing the integer identifier of the codec.

cid.version

Property containing the CID version integer.

cid.multihash

Property containing the multihash Uint8Array.

cid.multibaseName

Property containing the default base to use when calling .toString

cid.bytes

Property containing the full CID encoded as a Uint8Array.

cid.prefix

Proprety containing a Uint8Array of the CID version, codec, and the prefix section of the multihash.

cid.toV0()

Returns the CID encoded in version 0. Only works for dag-pb codecs.

Throws if codec is not dag-pb.

cid.toV1()

Returns the CID encoded in version 1.

cid.toBaseEncodedString(base=this.multibaseName)

Returns a base encoded string of the CID. Defaults to the base encoding in this.multibaseName.

The value of this.multibaseName depends on how the instance was constructed:

If the CID was constructed from an object that already had a multibase (a string or an existing CID) then it retains that base.
If the CID was constructed from an object that did not have a multibase (a Uint8Array, or by passing only version + codec + multihash to the constructor), then multibaseName will be base58btc for a v0 CID or base32 for a v1 CID.

cid.toString(base=this.multibaseName)

Shorthand for cid.toBaseEncodedString described above.

cid.equals(cid)

Compare cid instance. Returns true if CID's are identical, false if otherwise.

Contribute

Contributions welcome. Please check out the issues.

Check out our contributing document for more information on how we work, and about contributing in general. Please be aware that all interactions related to multiformats are subject to the IPFS Code of Conduct.

Small note: If editing the Readme, please conform to the standard-readme specification.

License

MIT

js-cid's People

Contributors

Stargazers

Watchers

js-cid's Issues

Warn when `toString` behavior will be different.

js-multiformats introduced more deterministic behavior of toString() method which could lead to a different behavior in comparison to .toString() method here.

We should amend .toString() method implementation here to print a warning in instances where behavior exhibited by js-multiformats would defer and provide a link to migration guide.

CIDs across the message channels

In the context ipfs/js-ipfs#3022 I'm running into problem with CIDs that is not too dissimilar from ones that come from Buffers. I would like to bring those up here for a discussion.

Problem

When you post things across browsing contexts data browsers perform structured cloning which implies that only handful of things will come out with the same prototype chain on the other end. Including table from MDN below:

Supported types

Object type	Notes
All primitive types	However, not symbols.
Boolean objects
String objects
Date
RegExp	`lastIndex` is not preserved.
`Blob`
`File`
`FileList`
ArrayBuffer
ArrayBufferView	Including other typed arrays.
`ImageBitmap`
`ImageData`
Array
Object	Only plain objects (e.g. from object literals)
Map
Set

This implies that node Buffers come out as Uint8Arrays (as they are sub-classes) and CIDs come out as plain objects, that is following most of the time:

{
  version: 0|1,
  codec: string,
  multihash: Uint8Array,
  multibaseName: string
}

Which is problematic because e.g. dag-cbor encoder will not recognize such structures as CID and would encode it as JSON. In other words only way for things to work across message-channel we need either to:

DeepCopy+Encode -> Structure Clone -> Traverse+Decode
- Sender needs to deep-copy arbitrary data structures to swap CIDs with some encoded version.
- Which browser will structure clone (another copy).
- Receiver needs to traverse inputs to find endoced CIDs and swap those with decoded instances (I think copying can be avoided here)
Structure Clone -> Traverse+Decode
- CID class can be made recognizable to remove need for deep-copy + CID encoding.
- Browser will structure clone.
- Receiver will traverse inputs to find structure cloned CIDs and swap those with decoded instances

Neither of two is ideal. What would be much better if CID had a canonical representation that is not tied to specific class. Kind of how ArrayBuffer represents bytes and Uint8Array is just a view.

I am recognizing that this might be almost impossible change to make at this point, however it is still worse having a discussion I think. Furthermore there might be certain compromises that may provide workable compromise. E.g. if all the IPFS internals did recognized canonical representation which is not tied to CID class that would remove need for decode / encode at least on messages going from client to server. I can also imagine that new Block API might be made to recognize that canonical representation which would effectively remove need for arbitrary traversals and limit CID encode / decode to very specific API endpoints.

/cc @mikeal @vmx @achingbrain @hugomrdias @lidel

Typescript is confused by constructor overload in the defs

Current type defs for the CIDs have bunch of overloads for the construction function, which seems to confuse typescript in some call patterns.

Drop class-is dependecy

Suggestion to drop class-is dependency an implementing isCID locally came from the discussion in moxystudio/js-class-is#25

Submitting issue here for further discussions.

Keep the api just without class-is, implement isCID with instanceof with fallback to validating the components

@hugomrdias what do you mean by validating components ?

At the moment as far as I understand isCID just boils down to:

obj && obj[Symbol.for('@ipld/js-cid/CID')]

Are you suggesting new CID.isCID should be something along these lines:

class CID {
  static typeSymbol: Symbol.for('@ipld/js-cid/CID')
  static isCID(value) {
    return value instanceof CID || (value && value[CID.typeSymbol])
  }
}

Or do you meant something like:

class CID {
  static isCID(value) {
    return value instanceof CID || CIDUtil.checkCIDComponents(other) == null
  }
}

If later that would be pretty wonderful, and step towards #109. On the other hand it may break some assumptions about the availability of certain instance methods.

I think it would be better to avoid such a dramatic change of isCID and just let it be a glorified instanceof check. Instead I would propose to introduce asCID static method as described in #111 (originally I wrote it up here, but decided it would be better to move into separate thread)

Deprecate `.mulibaseName` property

js-multiformats removed .mulibaseName property. To ease the transition we should print a deprecation warning on first access and link to the migration guide. Current plan is to keep warning indefinitely, that is until migration to js-multiformats

A way to compare CIDs for equality

Is there a way to compare two CIDs for equality of the hash itself? I am guessing that because I have a different versions of it, base encoding is different? Or is this not possible?

Webpack bundle failing at CID: Unexpected token: name (CID)

Hey guys, I'm trying to bundle https://github.com/ipfs/js-ipfs, and they're using cids.

Whenever I try to build, yarn run build, with create-react-app, I'm getting this error:

static/js/main.d24ead13.js from UglifyJs
Unexpected token: name (CID) [./~/cids/src/index.js:23,0][static/js/main.d24ead13.js:8442,6]

looks like uglifyJS doesn't look CID? tracked it down to your package and was wondering if you had any insights.

Unable to build because of this.

Buffer instead of Uint8Array

I lately upgrade js-cid from 0.8.3 to 1.0.0 who is a major upgarde as Uint8Array are used instead of Buffer.

However it appears that js-multibase do not always return Uint8Arrays.
I've a set of tests who crashed immediately when upgraded

ipfs cidv0 to ipfs cidv1 (base58btc, dag-pb) and vice versa
ipns cidv0 to ipns cidv1 (base58btc, dag-pb) to (base32, libp2p-key) and vice versa
ipns cidv1 to ipns cidv1 (base32, libp2p-key) to (base36, lip2p-key) and vice versa

According to :
https://github.com/multiformats/js-multibase/blob/master/src/constants.js

base58btc (dag-pb) who is used in IPFS cidv0 returns a Buffer
base36 (libp2p-key) who is used in IPNS cidv1 returns a Buffer

Thanks

Deprecate construction with `codec`

js-multiformats throws when constructing with codec, to ease the future transition we should introduce a warning with a link to migration guide.

Plan is to keep that warning indefinitely until we migrate to js-multiformats.

Improve isCID?

isCID checks version, codec and multihash properties are present and validates them. This proves that the passed object is an object that looks like { version, codec, multihash } and each property is valid, but doesn't actually prove that the passed object is an instance of CID.

So you could get back a true from isCID but there's a possibility that toBaseEncodedString (and the other instance methods) don't exist!

I know it's not the perfect solution, but would using https://github.com/moxystudio/js-class-is be better?

It's still possible to "fake" a CID instance, but it's much harder to do it by accident and we might even get a performance win if we make version, codec, and multihash readonly, because we can safely assume they are valid if we can determine the passed object is an instance of CID.

An in-range update of multibase is breaking the build 🚨

Version 0.3.4 of multibase just got published.

Branch	Build failing 🚨
Dependency	multibase
Current Version	0.3.3
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

As multibase is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Status Details

✅ ci/circleci Your tests passed on CircleCI! Details
❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 3 commits .

18623b0 chore: release version v0.3.4
9032246 chore: update contributors
04b378c chore: update aegir and fix linting

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

Your Greenkeeper Bot 🌴

toString doesn't work

toString does not appear to be implemented, there is a toBaseEncodedString which is not here in the docs, and appears to only encode the multihash portion.

What I'm really looking for is a reversible pair of functions to take the CID from and to a string, and either they aren't there, or it would be great to get documentation of what the inverse of cid.toBaseEncodedString is ?

Trying to hack the way around Webpack build

Trying to find a workaround for the issue #38, I made a script to babelify every script that couldn't be parsed by webpack:

fix.js, click to expand

var exec = require('child_process').exec;

var files = [
"node_modules/cids/src/index.js",
"node_modules/borc/src/utils.js",
"node_modules/datastore-core/src/keytransform.js",
"node_modules/datastore-core/src/shard.js",
"node_modules/datastore-level/src/index.js",
"node_modules/interface-datastore/src/key.js",
"node_modules/interface-datastore/src/utils.js",
"node_modules/ipfs-bitswap/src/utils.js",
"node_modules/ipfs-bitswap/src/types/message/index.js",
"node_modules/ipfs-bitswap/src/types/wantlist/index.js",
"node_modules/ipfs-block/src/index.js",
"node_modules/ipfs-block-service/src/index.js",
"node_modules/ipfs-repo/src/index.js",
"node_modules/ipfs-repo/src/lock-memory.js",
"node_modules/ipfs-unixfs/src/index.js",
"node_modules/ipfs-unixfs-engine/src/importer/dir.js",
"node_modules/ipld-ethereum/util/createTrieResolver.js",
"node_modules/ipld-ethereum/util/createResolver.js",
"node_modules/ipld-dag-cbor/src/util.js",
"node_modules/ipld-dag-pb/src/dag-link/index.js",
"node_modules/ipld-dag-pb/src/dag-node/create.js",
"node_modules/ipld-dag-pb/src/dag-node/util.js",
"node_modules/ipld-dag-pb/src/dag-node/index.js",
"node_modules/ipld-dag-pb/src/util.js",
"node_modules/ipld-git/src/util/util.js",
"node_modules/libp2p-crypto/src/nodeify.js",
"node_modules/libp2p-crypto/src/webcrypto.js",
"node_modules/libp2p-crypto/src/keys/keys.proto.js",
"node_modules/libp2p-secio/src/support.js",
"node_modules/libp2p-secio/src/handshake/crypto.js",
"node_modules/libp2p-swarm/src/protocol-muxer.js",
"node_modules/mafmt/src/index.js --out-file node_modules/mafmt/src/index.js",
"node_modules/multiaddr/src/index.js",
"node_modules/multicodec/src/name-table.js",
"node_modules/multicodec/src/util.js",
"node_modules/multicodec/src/varint-table.js",
"node_modules/multihashes/src/index.js",
"node_modules/multihashing-async/src/index.js",
"node_modules/multihashing-async/src/utils.js",
"node_modules/multistream-select/src/util.js",
"node_modules/peer-id/src/index.js",
"node_modules/peer-info/src/index.js",
"node_modules/smart-buffer/build/smartbuffer.js",
"node_modules/borc/src/simple.js",
"node_modules/borc/src/tagged.js",
"node_modules/ipld-dag-cbor/src/resolver.js",
"node_modules/ipld-git/src/util.js",
"node_modules/ipld-git/src/resolver.js",
"node_modules/ipld-ethereum/util/createIsLink.js",
"node_modules/ipld-ethereum/util/createUtil.js",
"node_modules/libp2p-crypto/src/hmac/index-browser.js",
"node_modules/libp2p-crypto/src/keys/rsa-browser.js",
"node_modules/libp2p-crypto/src/util.js",
"node_modules/peer-book/src/index.js",
"node_modules/multistream-select/src/select.js",
"node_modules/libp2p-identify/src/message.js",
"node_modules/libp2p-swarm/src/plaintext.js",
"node_modules/libp2p-swarm/src/get-peer-info.js",
"node_modules/ipfs-pubsub-room/src/encoding.js",
"node_modules/ipfs/src/core/index.js",
"node_modules/ipld-resolver/src/index.js",
"node_modules/multibase/src/index.js",
"node_modules/multibase/src/constants.js",
"node_modules/multibase/src/base.js",
"node_modules/multibase/src/base16.js",
"node_modules/multicodec/src/index.js",
"node_modules/ipfs-repo/src/version.js",
"node_modules/interface-datastore/src/memory.js",
"node_modules/ipfs-repo/src/config.js",
"node_modules/ipfs-repo/src/api-addr.js",
"node_modules/ipfs-repo/src/blockstore.js",
"node_modules/datastore-core/src/sharding.js",
"node_modules/datastore-core/src/shard-readme.js",
"node_modules/datastore-core/src/mount.js",
"node_modules/datastore-core/src/tiered.js",
"node_modules/datastore-core/src/namespace.js",
"node_modules/multihashing-async/src/crypto-sha1-2-browser.js",
"node_modules/multihashing-async/src/blake.js",
"node_modules/ipld-dag-pb/src/dag.proto.js",
"node_modules/ipld-dag-pb/src/dag-node/rmLink.js",
"node_modules/ipld-dag-pb/src/resolver.js",
"node_modules/borc/src/diagnose.js",
"node_modules/borc/src/encoder.js",
"node_modules/borc/src/decoder.js",
"node_modules/ipld-git/src/util/commit.js",
"node_modules/ipld-git/src/util/tag.js",
"node_modules/ipld-git/src/util/tree.js",
"node_modules/ipld-ethereum/eth-block-list/index.js",
"node_modules/ipld-ethereum/util/toIpfsBlock.js",
"node_modules/ipld-raw/src/index.js",
"node_modules/libp2p-crypto/src/aes/index.js",
"node_modules/libp2p-crypto/src/keys/index.js",
"node_modules/libp2p-crypto/src/keys/rsa-class.js",
"node_modules/libp2p-crypto/src/keys/ed25519-class.js",
"node_modules/libp2p-crypto/src/keys/ed25519.js",
"node_modules/libp2p-crypto-secp256k1/src/index.js",
"node_modules/libp2p-crypto-secp256k1/src/crypto.js",
"node_modules/libp2p-crypto/src/keys/key-stretcher.js",
"node_modules/libp2p-crypto/src/keys/ephemeral-keys.js",
"node_modules/libp2p-crypto/src/keys/ecdh-browser.js",
"node_modules/multiaddr/src/codec.js",
"node_modules/peer-info/src/multiaddr-set.js",
"node_modules/ipfs/src/core/boot.js",
"node_modules/ipfs/src/core/components/pre-start.js",
"node_modules/ipfs/src/core/components/start.js",
"node_modules/ipfs-bitswap/src/index.js",
"node_modules/ipfs-bitswap/src/want-manager/index.js",
"node_modules/varint-decoder/src/index.js",
"node_modules/ipfs-bitswap/src/types/message/message.proto.js",
"node_modules/ipfs-bitswap/src/types/message/entry.js",
"node_modules/ipfs-bitswap/src/types/wantlist/entry.js",
"node_modules/ipfs-bitswap/src/want-manager/msg-queue.js",
"node_modules/ipfs-bitswap/src/network.js",
"node_modules/pull-length-prefixed/src/encode.js",
"node_modules/pull-length-prefixed/src/decode.js",
"node_modules/ipfs-bitswap/src/decision-engine/index.js",
"node_modules/ipfs-bitswap/src/decision-engine/ledger.js",
"node_modules/ipfs-bitswap/src/notifications.js",
"node_modules/libp2p-floodsub/src/index.js",
"node_modules/time-cache/src/index.js",
"node_modules/libp2p-floodsub/src/peer.js",
"node_modules/libp2p-floodsub/src/message/rpc.proto.js",
"node_modules/libp2p-floodsub/src/message/topic-descriptor.proto.js",
"node_modules/libp2p-floodsub/src/utils.js",
"node_modules/ipfs/src/core/components/stop.js",
"node_modules/ipfs/src/core/components/is-online.js",
"node_modules/ipfs/src/core/components/version.js",
"node_modules/ipfs/src/core/components/id.js",
"node_modules/ipfs/src/core/components/repo.js",
"node_modules/ipfs/src/core/components/init.js",
"node_modules/ipfs/src/core/components/bootstrap.js",
"node_modules/ipfs/src/core/components/config.js",
"node_modules/ipfs/src/core/components/block.js",
"node_modules/ipfs/src/core/components/object.js",
"node_modules/ipfs-unixfs/src/unixfs.proto.js",
"node_modules/ipfs/src/core/components/dag.js",
"node_modules/ipfs/src/core/components/libp2p.js",
"node_modules/ipfs/src/core/runtime/libp2p-browser.js",
"node_modules/libp2p-websockets/src/index.js",
"node_modules/interface-connection/src/connection.js",
"node_modules/libp2p-websockets/src/ma-to-url.js",
"node_modules/libp2p-websockets/src/listener.js",
"node_modules/libp2p-webrtc-star/src/index.js",
"node_modules/libp2p-webrtc-star/src/utils.js",
"node_modules/libp2p-multiplex/src/index.js",
"node_modules/multiplex/src/index.js",
"node_modules/multiplex/src/channel.js",
"node_modules/libp2p-multiplex/src/muxer.js",
"node_modules/libp2p-secio/src/index.js",
"node_modules/libp2p-secio/src/handshake/index.js",
"node_modules/libp2p-secio/src/handshake/propose.js",
"node_modules/libp2p-secio/src/handshake/secio.proto.js",
"node_modules/libp2p-secio/src/handshake/exchange.js",
"node_modules/libp2p-secio/src/handshake/finish.js",
"node_modules/libp2p-secio/src/etm.js",
"node_modules/libp2p-secio/src/state.js",
"node_modules/libp2p-railing/src/index.js",
"node_modules/libp2p/src/index.js",
"node_modules/libp2p-ping/src/handler.js",
"node_modules/libp2p-ping/src/ping.js",
"node_modules/libp2p-ping/src/util.js",
"node_modules/libp2p-swarm/src/index.js",
"node_modules/libp2p-swarm/src/transport.js",
"node_modules/multistream-select/src/listener/index.js",
"node_modules/multistream-select/src/listener/select-handler.js",
"node_modules/multistream-select/src/listener/ls-handler.js",
"node_modules/multistream-select/src/dialer/index.js",
"node_modules/libp2p-swarm/src/limit-dialer/index.js",
"node_modules/libp2p-swarm/src/limit-dialer/queue.js",
"node_modules/libp2p-swarm/src/connection.js",
"node_modules/libp2p-identify/src/listener.js",
"node_modules/libp2p-identify/src/dialer.js",
"node_modules/libp2p-swarm/src/dial.js",
"node_modules/ipfs/src/core/components/swarm.js",
"node_modules/ipfs/src/core/components/ping.js",
"node_modules/ipfs/src/core/components/files.js",
"node_modules/ipfs-unixfs-engine/src/importer/index.js",
"node_modules/ipfs-unixfs-engine/src/builder/create-build-stream.js",
"node_modules/ipfs-unixfs-engine/src/builder/builder.js",
"node_modules/ipfs-unixfs-engine/src/builder/reduce.js",
"node_modules/ipfs-unixfs-engine/src/builder/flat/index.js",
"node_modules/ipfs-unixfs-engine/src/builder/balanced/balanced-reducer.js",
"node_modules/ipfs-unixfs-engine/src/builder/trickle/trickle-reducer.js",
"node_modules/ipfs-unixfs-engine/src/importer/tree-builder.js",
"node_modules/ipfs-unixfs-engine/src/importer/dir-flat.js",
"node_modules/ipfs-unixfs-engine/src/importer/flat-to-shard.js",
"node_modules/ipfs-unixfs-engine/src/importer/dir-sharded.js",
"node_modules/ipfs-unixfs-engine/src/hamt/bucket.js",
"node_modules/sparse-array/index.js",
"node_modules/ipfs-unixfs-engine/src/hamt/consumable-hash.js",
"node_modules/ipfs-unixfs-engine/src/hamt/consumable-buffer.js",
"node_modules/ipfs-unixfs-engine/src/chunker/fixed-size.js",
"node_modules/ipfs-unixfs-engine/src/exporter/index.js",
"node_modules/ipfs-unixfs-engine/src/exporter/dir-flat.js",
"node_modules/ipfs-unixfs-engine/src/exporter/dir-hamt-sharded.js",
"node_modules/ipfs-unixfs-engine/src/exporter/clean-multihash.js",
"node_modules/ipfs-unixfs-engine/src/exporter/file.js",
"node_modules/ipfs-unixfs-engine/src/exporter/object.js",
"node_modules/ipfs/src/core/components/bitswap.js",
"node_modules/ipfs/src/core/components/pubsub.js",
"node_modules/ipfs/src/core/components/dht.js",
"node_modules/ipfs/src/core/runtime/repo-browser.js",
"node_modules/ipfs/src/core/state.js",
"node_modules/y-ipfs-connector/src/index.js",
"node_modules/ipfs-pubsub-room/src/index.js",
"node_modules/hyperdiff/lib/index.js",
"node_modules/ipfs-pubsub-room/src/connection.js",
"node_modules/y-ipfs-connector/src/encode.js",
"node_modules/y-ipfs-connector/src/decode.js",
"node_modules/cids/node_modules/multicodec/src/varint-table.js",
"node_modules/cids/node_modules/multicodec/src/util.js",
"node_modules/ipfs-block/node_modules/cids/src/index.js",
"node_modules/cids/node_modules/multicodec/src/index.js",
"node_modules/cids/node_modules/multicodec/src/name-table.js"
]

files.map(function(file){
console.log("Fixing " + file)
exec("node_modules\.bin\babel " + file + " --out-file " + file + " --presets=es2015",
function(err, stdout, stderr){
if (stdout) console.log(stdout)
if (stderr) console.error(stderr)
if (err) console.error(err)
}
)
})

I just added babel as dev dependency (yarn add babel-cli --dev) and run this script (node fix).

However, I still have an error:

Uncaught Error: second argument must be a CID
    at new e (index.js:29) // ipfs-block
    at index.js:381 // ipld-resolver
    at n (waterfall.js:16) // async
    at r (waterfall.js:23) // async
    at onlyOnce.js:12 // async/internal
    at Object.o [as serialize] (util.js:27) //ipld-dag-pb
    at index.js:379 //ipld-resolver
    at n (waterfall.js:16) // async
    at t.default (waterfall.js:26) // async
    at e.value (index.js:378) //ipld-resolver

I don't know the internal of ipfs (yet), so if anyone has an idea of what could cause this bug, I take it 😉

Proposal: Moving CID to multiformats Org

Please review multiformats/cid#26

Enable CI

I don't have access currently to enable travis and circle. I requested the permissions via github.

An in-range update of multihashes is breaking the build 🚨

Version 0.4.4 of multihashes just got published.

Branch	Build failing 🚨
Dependency	multihashes
Current Version	0.4.3
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

As multihashes is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Status Details

✅ ci/circleci Your tests passed on CircleCI! Details
❌ coverage/coveralls Coverage pending from Coveralls.io Details
❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 4 commits .

78ef8de chore: release version v0.4.4
f039a2f chore: update contributors
f6da734 chore: release version v0.3.4
e5c581c chore: update aegir, fix new linting

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

Your Greenkeeper Bot 🌴

Releases >1.1.0 are broken

It looks like the build assets are being nested in a "dist" folder upon npm publish. This appears to have been introduced in 0e11f03? I think the fix is to use a glob pattern here: 0e11f03#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R20 Or possibly fixing how the build folders are produced?

This mostly only affects typescript types, but relative path imports might also be affected?

Check why Windows CI is failing

Windows was failing recently https://github.com/multiformats/js-cid/pull/94/checks. Have a closer look at fix it.

Bump version to 1.0

We depend on this enough that I’d like some guarantees and practices around breaking changes. The first step is to push what is here as 1.0.

CID as ArrayBufferView

Change CID representation to a glorified ArrayBuffer view (as per #111 & multiformats/js-multiformats#29).

Primary goal here is to make CID a view into ArrayBuffer slice instead of encoding / decoding of bytes. That being said we will still retain API compatibilitiy, meaning encoding / decoding CIDs would still be supported as is.

CID constructor throws when multihash uses "identity" algortihm

Following code throws exception:

const mh = multihash.encode(Buffer.from('abc'), 'identity')
const cid = new CID(0, 'dag-pb', mh)
// Uncaught Error: multihash unknown function code: 0x0

An in-range update of multicodec is breaking the build 🚨

Version 0.1.7 of multicodec just got published.

Branch	Build failing 🚨
Dependency	multicodec
Current Version	0.1.6
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

As multicodec is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Status Details

✅ ci/circleci Your tests passed on CircleCI! Details
✅ coverage/coveralls First build on greenkeeper/multicodec-0.1.7 at 85.965% Details
❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 3 commits .

5f5c359 chore: release version v0.1.7
c3e9ac5 chore: update contributors
8ba4409 chore: update aegir

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

Your Greenkeeper Bot 🌴

Provide non-generic constructor methods

I would very much like to make construction of CID's less generic as it really reduces cognitive overhead (saves you from side-trips) when reading code that does new CID(x) because from the context x can be many different things.

Which that goal in mind I'd like to propose adding distinct distinct static methods:

CID.fromCID(cid) - Does that even makes sense ? Should there maybe a clone() method instead ?
CID.fromBaseEncodedString(BaseEncodedString) or maybe CID.parse(BaseEncodedString)
CID.fromBuffer(Buffer) or better yet CID.decode(Buffer)
CID.fromJSON(SerializedCID)

Ideally CID() then could be made non generic CID(Version, Codec, Multihash, name:MultibaseName='base58btc') I would even go and make last param mandatory. If really desired generic version could also be added: CID.from(CID|BaseEncodedString|Buffer|SerializedCID):CID<a> (although I'd prefer not to)

I do understand that maybe changing constructor API might be too big of a breaking change so I propose to gradually fade it out. Maybe initially CID.create(Version, Codec, Multihash, MultibaseName) could be added instead and slowly migrate users to new ways until it's safe to make a switch.

toBaseEncodedString should default to the base of the cid string use to construct the instance

Where a CID instance is constructed from a string, we should preserve the base that it was given in, and use it as the default base when toBaseEncodedString is called, so the information is not lost.

In IPLD explorer, we construct a CID from a user provided string. That means we lose the information about the base encoding we were given. See: ipfs/ipfs-webui#999

Ideally we'd have it so you could

const Cid = require('cids')
const x = new Cid('bafybeihj5nwgbaan7eh4ryrx5vjsi3zzn2dvpgv2ibvku6lwublilhxcfu')

x.toString()
// 'bafybeihj5nwgbaan7eh4ryrx5vjsi3zzn2dvpgv2ibvku6lwublilhxcfu'

x.toBaseEncodedString()
// 'bafybeihj5nwgbaan7eh4ryrx5vjsi3zzn2dvpgv2ibvku6lwublilhxcfu'

x.toBaseEncodedString('base58btc')
// 'zdj7WmB2HKhmNYQT1nRJaJckMuvLJChCAvwuKA7jXvfzZEJ1a'

const y = new Cid('zdj7WmB2HKhmNYQT1nRJaJckMuvLJChCAvwuKA7jXvfzZEJ1a')

x.toString()
// 'zdj7WmB2HKhmNYQT1nRJaJckMuvLJChCAvwuKA7jXvfzZEJ1a'

x.toBaseEncodedString()
// 'zdj7WmB2HKhmNYQT1nRJaJckMuvLJChCAvwuKA7jXvfzZEJ1a'

x.toBaseEncodedString('base32')
// 'bafybeihj5nwgbaan7eh4ryrx5vjsi3zzn2dvpgv2ibvku6lwublilhxcfu'

Deprecate `.toBaseEncodedString` method in favor of `.toString()`

js-multiformats has deprecated .toBaseEncodedString(), to ease the future transition we should:

Introduce a deprecation warning suggesting to use toString() instead.

Plan is to keep it indefinitely, that is until switch to js-multiformats.

how to convert from hex to cid.

Let’s say I get the cid when I push a file to ipfs. now, I need to store it in solidity’s bytes variable. because it’s a bytes variable, i can’t directly send cid as it will fail. So I transform the cid into hex depending on which base the cid uses. The hex goes to solidity.

After some time, solidity throws the event which I catch in my another client(javascript). Now I need to somehow get the CiD again from this hex. How do I do this ? The tricky part is that I don’t know if while getting the hex, which base was used which means I could have gotten the hex of cid v0 or v1.

What would be the right way ? Definatelly, I need to know which base was used so that I can decode from hex to cid again.

An in-range update of multihashing-async is breaking the build 🚨

Version 0.4.1 of multihashing-async just got published.

Branch	Build failing 🚨
Dependency	multihashing-async
Current Version	0.4.0
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As multihashing-async is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Status Details

✅ ci/circleci Your tests passed on CircleCI! Details
❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Release Notes

v0.4.1

Features

change window to self for webworker support (d89e039)

Commits

The new version differs by 3 commits .

4829db0 chore: release version v0.4.1
e5b8ebe chore: update contributors
d89e039 feat: change window to self for webworker support

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

Your Greenkeeper Bot 🌴

An in-range update of multihashing-async is breaking the build 🚨

Version 0.4.3 of multihashing-async just got published.

Branch	Build failing 🚨
Dependency	multihashing-async
Current Version	0.4.2
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Status Details

✅ ci/circleci Your tests passed on CircleCI! Details
❌ coverage/coveralls Coverage pending from Coveralls.io Details
❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Release Notes

v0.4.3

Features

add blake support (303a94c)

Commits

The new version differs by 4 commits .

b65cdd7 chore: release version v0.4.3
d7bf9d8 chore: update contributors
6a6292d Merge pull request #17 from multiformats/blake
303a94c feat: add blake support

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

Your Greenkeeper Bot 🌴

Build issue in Angular 8 project (with resolution)

I have an Angular project using some ipfs related packages with cids as a dependency. My ng build fails with the following error:

ERROR in ./node_modules/cids/src/index.js
Module not found: Error: Can't resolve 'multicodec/src/base-table'

Upon investigation, I found that cids has multicodec as a dependency, and attempts to import a json file using require without specifying the file suffix. This results in the file not being identified and the aforementioned error. By specifying 'multicodec/src/base-table.json' the issue can be bypassed.

I'm happy to submit a patch if you like. I'd like to get this fixed in the upstream so I don't have to patch it locally in a postinstall step. I believe it is not considered best practice to import json in this way, so I'd propose it be imported using fs.readFile/JSON.parse, but the remedy above works as well.

Module not found: Can't resolve 'multicodec/src/base-table.json'

Only seeing .js in that lib

CIDs with dag-cbor formats as V0 addresses

I'm trying to retrieve a DAG persisted with the following options via webui. As I understand it, to do so I have to convert to a V0 address as per — https://github.com/ipld/js-cid/blob/38e5dd0f5e89a750d9f20efefdaa00d38b287739/test/index.spec.js#L81 :
const dagOpts = { format: 'dag-cbor', hashAlg: 'sha3-512' };

I have the following code that results in an error — 'Cannot convert a non dag-pb CID to CIDv0' :

      let cid  = new CID("zdpuAypJXbmGCLweJBL6R1iBpDGJyP8LU1BwZjzRjwNxohzvE");
     console.log(cid.toV0());

Is it possible at all to access objects of format dag-cbor type from webui or IPFS cli?

Add method to provide the human readable version

Provide a simple way to get at the human readable version of the CID as defined here: https://github.com/ipld/cid#human-readable-cids

Prior art: https://github.com/ipfs-shipyard/ipld-explorer/blob/ff64b2fba5ad556af83617a488dc5a7b71aad572/src/lib/cid.js#L26-L80

Improve constructor performance

When I was doing some profiling I found out that if loading a lot of blocks from storage, new CID gets in to pretty hot code paths and starts becoming a bottleneck. Specifically the CID.isCID is not well optimized as it uses try catch to determine if we already have a CID

An in-range update of multihashing-async is breaking the build 🚨

Version 0.4.5 of multihashing-async just got published.

Branch	Build failing 🚨
Dependency	multihashing-async
Current Version	0.4.4
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Status Details

✅ ci/circleci Your tests passed on CircleCI! Details
❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details
✅ coverage/coveralls First build on greenkeeper/multihashing-async-0.4.5 at 85.965% Details

Commits

The new version differs by 5 commits .

8ebf348 chore: release version v0.4.5
6f10df7 chore: update contributors
c3ea0b8 chore: update deps
3efb676 murmur3 should output 128 bit instead of 32 (#21)
71aa4d3 chore: use dirty-chai

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

Your Greenkeeper Bot 🌴

description

If I'm any indication, readers might not know what a CID is. It might be worth mentioning briefly what this module does and any necessary background context required.

Pulish latest changes to npm

As requested here could you publish latest changes to npm please ?

Clarify intent of type parameter in type defs

This question came up #79 (comment)

I should have noted what type parameter was for as it’s absolutely unclear. Creating this issue, so I can fix it by adding comments clarifing

API link in readme is broken

https://github.com/ipld/js-cid#api currently points to https://ipld.github.io/js-cid which returns 404

Deprecate `.prefix` property

js-multiformats removed .prefix property. Having it pretty questionable design choice. Current plan is:

Figure out if it can be removed from ipfs/js-ipfs-bitswap#244 (and elsewhere ?)
Introduce a deprecation warning with a link to the migration guide (until next major release).
Remove in the next release.

What is the purpose of `toJSON()`?

I'm a little confused by the toJSON() method.

First of all, we have doc comments for a typedef that doesn't actually exist called "SerializedCID". The docs claim toJSON() returns this but that isn't actually true.

In our toJSON() method we return 3 properties, one of which is a Buffer and, as a result, won't be property decodable from the JSON representation.

As I started to think about what toJSON() should do I realized that the most useful thing may be returning {"/": this.baseEncodedString()}. This touches again on the discussion we're having about a canonical JSON form for links but it does seem appropriate.

multicodec needs to be validated

Calling cid.buffer property throws the following exception when version==1:

 Uncaught TypeError: First argument must be a string, Buffer, ArrayBuffer, Array, or array-like object.
  at fromObject (buffer.js:262:9)
  at Function.Buffer.from (buffer.js:101:10)
  at CID.get buffer [as buffer] (/home/harry/.../js-ipfs/node_modules/cids/src/index.js:122:18)

How to reproduce

Create a CID object with version==1.
Call cid.buffer.

Proposal: Let's introduce `asCID` static method

This idea first was proposed in #109 and later came up in #110. I thought it would be best to factor it out into separate thread and discuss it here.

Problem

At the moment CID.isCID(v) is used all over the place as a glorified v instanceof CID check. However it does not check if v is instanceof CID instead it checks presence of special symbol. That addresses problem with having multiple different versions of CID implementations, however it does overlook the fact that two different version may in fact be incompatible e.g. new version may change behavior of specific method e.g. toString I think that is already happening (per #109 (comment))

In the new CID you can use .toString() with no arguments and it will give you a base32 multibase encoded string for CIDv1 and the bare base58btc encoding for CIDv0.

Even if above is backwards compatible change, incompatible change may come sooner or later.

This is a symptom of more general issue with validation pattern.
If you're inclined I would invite to read excellent parse don't validate primer that explains hazzards of that problem (in the context of typed language, but it applies to this just as well)

Proposal

Changing behavior of CID.isCID(v) to do component validation (if I interperent @hugomrdias suggestion moxystudio/js-class-is#25 (comment)) is going to be too disruptive to be worth it. Furthermore it would not address the problem stated above. Instead I would like to propose an alternative in form of asCID static method to which existing code base could be gradually migrated and future code base should default.

Implementation could be something along these lines:

class CID {
  /**
   * If passed value is a CID or compatible JSON representation, CID instance for it is returned
   * otherwise `null` is returned.
   * returns `null`.
   * @param {any} value
   * @returns {CID|null}
   */
  asCID(value) {
    // If is CID nothing to do here
     if (value instanceof CID) {
       return value
     }
     // If CID components validate it's CID from other realm or another version of CID
     // In that case CID of this class is assembled from the components.
     else if (CIDUtil.checkCIDComponents(other) == null) {
       return new CID(value.version, value.codec, value.multihash, value.multibaseName)
     }
     // Otherwise it's not valid / compatible CID so return `null`
     else {
       return null
     }
  }
}

With such method in place existing pattern of

if (CID.isCID(cid)) {
  // use cid
}

Could gradually be transitioned to following pattern instead:

const cid = CID.asCID(value)
if (cid) {
   // use cid
}

It is a bit more verbose, but it would avoid issues that may arise from version incompatibilities. It will also preserve CID-ness when things are structured cloned.

Make it match the go Implementation

Ref: https://discuss.ipfs.io/t/how-are-the-dag-link-buffers-encoded-js-ipfs/1310/5

Deprecate `.codec` property with a warning

We should emit a warning first time .codec property is accessed, that provides link to the instructions for migration from .codec to .code. Current plan is to have it indefinitely, that is until we ipfs ecosystem migrates to js-multiformats.

The reason we want warnings is because users usually get CID e.g. by calling const { cid } = await ipfs.add(...), so this could provide room for migration instead of clean break.

Follow the spec for decoding a string CID

https://github.com/multiformats/cid#decoding-algorithm

When decoding a CIDv0 string we just try to decode with base58btc, when we should first check the string begins with Qm and is 46 characters long.

Base encoding is incorrect

The current implementation of toBaseEncodedString() is https://github.com/ipld/js-cid/blob/185625002b248771a3586aac0800323102cd5e2c/src/index.js#L96-L107 -- this is incorrect.

It should be:

  toBaseEncodedString (base) {
    base = base || 'base58btc'

    switch (this.version) {
      case 0:
      case 1:
        return multibase.encode(base, this.buffer).toString()
      default:
        throw new Error('Unsupported version')
    }
  }

both case 0 and case 1 should return the proper base encoded version, and should return a CIDv1 link. if we want to enable returning a CIDv0 link, that should be an explicit flag or a different function. otherwise it leads to incorrect and confusing behavior.

Consider this:

> var hash = 'QmPZ9gcCEpqKTo6aq61g2nXGUhM4iCL3ewB6LDXZCtioEB'
> var CID = require('cids')
> var id = new CID(hash)
> console.log(id.toBaseEncodedString('base16'))
"QmPZ9gcCEpqKTo6aq61g2nXGUhM4iCL3ewB6LDXZCtioEB"

That's totally borked. like mega borked.

BTW, we NEED to be able to express old CIDv0 links as the new CIDv1 links, particularly for browser support where the "host" part of the URI MUST be case insensitive (this is needed to support ipfs://<hash> which is needed because people cannot specify the origin to browsers, but MUST give it in the URI. we dont want ipfs to be the origin, we want <hash> or <name>. so this means only base32 or base16 hashes there. thanks to origin policy).

README has some methods which are missing

I tried methods and properties listed in README and some are missing:

hash
prefix

$ node
> const CID = require('cids')
> const cid = new CID('z8mWaJHXieAVxxLagBpdaNWFEBKVWmMiE')
> console.log(`my cid: ${cid}`)
my cid: [object Object]
>

...but get back my cid: z8mWaJHXieAVxxLagBpdaNWFEBKVWmMiE

It's basically a 3 line addition:

toString (base) {
  return this.toBaseEncodedString(base)
}

multiformats / js-cid Goto Github PK

js-cid's Introduction

js-cid

Lead Maintainer

Table of Contents

Install

In Node.js through npm

Browser: Browserify, Webpack, other bundlers

In the Browser through <script> tag

Usage

API

CID.isCID(cid)

CID.validateCID(cid)

new CID(version, codec, multihash, [multibaseName])

new CID(baseEncodedString)

new CID(Uint8Array)

cid.codec

cid.code

cid.version

cid.multihash

cid.multibaseName

cid.bytes

cid.prefix

cid.toV0()

cid.toV1()

cid.toBaseEncodedString(base=this.multibaseName)

cid.toString(base=this.multibaseName)

cid.equals(cid)

Contribute

License

js-cid's People

Contributors

Stargazers

Watchers

Forkers

js-cid's Issues

Problem

Supported types

Version 0.3.4 of multibase just got published.

Version 0.4.4 of multihashes just got published.

Version 0.1.7 of multicodec just got published.

Version 0.4.1 of multihashing-async just got published.

Features

Version 0.4.3 of multihashing-async just got published.

Features

Version 0.4.5 of multihashing-async just got published.

How to reproduce

Problem

Proposal

Recommend Projects

Recommend Topics

Recommend Org

In the Browser through `<script>` tag