Looks good to me! I also have sketched what we discussed in the call here
multiformats/js-cid#111 (comment)

Is it confusing to use the same property name for the instance and static class method?

Is it confusing to use the same property name for the instance and static class method?

I don't think so, as property is mostly for static method to recognize CID. That being said I really could not care less about property or static method name. Mostly went with asCID as it's one char different from isCID :)

I guess so ... it's pretty user-hostile though to be doing this in toJSON(), what does that look like if someone's using JSON.stringify() on a parent object for debugging?

That’s a good point.

Maybe we leave it out of toJSON() and just leave it enumerable. Most encoders probably enumerate the properties rather than using toJSON().

Should this be merged or do we need resolution on toJSON? It's been approved and sitting for a while.

Also, is the plan to replace the cids module everywhere? If so, is there a rollout plan for that?

Should this be merged or do we need resolution on toJSON? It's been approved and sitting for a while.

I’ll be returning to it eventually, other priorities have been getting in the way. I started this PR to fully consider the interface and I don’t feel like I’ve really had the time to do that yet.

Also, is the plan to replace the cids module everywhere? If so, is there a rollout plan for that?

Yes, some day, but not today :)

For js-ipfs this shouldn’t get adopted any time too soon, and should be part of a much larger change migrating to all the new Block and multiformats interfaces. But it’s premature to consider that given that we haven’t even updated our own stack to these changes.

I’ll join the IPFS implementations call on Monday to discuss these changes in more detail.

I'm strongly against breaking toJSON().

I'm strongly against breaking toJSON().

Ya, we won’t be, if this lands it’ll land without the toJSON() break.