IPFS addrs should use multihashes, not CIDs.
Opened this issue · 10 comments
The QmId part is actually just a bare base58 encoded multihash (for now). It's a direct hash of the peer's public key.
I assume you mean "Ipfs addrs should use Cids, not Multihashes"? And are you referring to the constructor?
In Java we've made Cid a subclass of Multihash, consistent with the v0-v1 move. So I think it is correct.
I assume you mean
Wow, that title was a train wreck.
But no, I meant multihases. The QmId in /ipfs/QmId... (or /p2p/QmId, the new version) is not a CID, it's a raw multihash. We have plans to make it a CID but have to think carefully about the upgrade path because, as it is, QmId... is a valid v0 CID but the "object" it points to (is a hash of) is a libp2p-crypto public key, not a merkledag node.
What about things like
https://ipfs.io/ipfs/zDMZof1kyVsgbhuNGjcSNSEeKTsgxsA3MArZm7BAogkC1iGRixef
I thought the part after the domain is a multiaddr?
As it stands the Java constructor for a Multiaddr already takes a Multihash (which could be a Cid or not)
What about things like
https://ipfs.io/ipfs/zDMZof1kyVsgbhuNGjcSNSEeKTsgxsA3MArZm7BAogkC1iGRixef
I thought the part after the domain is a multiaddr?
It's a path. Multiaddrs are for network/process addresses.
As it stands the Java constructor for a Multiaddr already takes a Multihash (which could be a Cid or not)
Note: arbitrary multihashes aren't valid CIDv0. Really, CIDv0 is defined to be a 256bit long base58 encoded sha2-256 multihash. Unfortunately, allowing arbitrary multihashes would cause conflicts with some multibase prefixes.
Not allowing Cids here is a problem, because Cid is a Multihash in Java (which I think was the right choice). And changing that is a significant rework of many projects. If you're going to upgrade to allow Cids, then we can just wait for that.
A CID may contain a multihash but they aren't the same thing (a CID isn't a type of multihash). Regardless, while we'll eventually likely allow CIDs in /ipfs/ multiaddrs, a /ipfs/ multiaddr is not the same thing as an /ipfs/ path.
I'm aware of that. I'm saying that I chose to make the Cid class a subclass of Multihash, so in Java a Cid is a Multihash in the type sense (This still seems like the right thing to do given my understanding of things).
To make things concrete, are there places in the http api (apart from things that take a multiaddr) where one can use a Multihash, but not a Cid?
To make things concrete, are there places in the http api (apart from things that take a multiaddr) where one can use a Multihash, but not a Cid?
Currently, everything that expects a peer ID expects a raw sha2-256 multihash. However, those'll still technically look like CIDs.
The primary issue here is that we're switching /ip4/.../tcp/.../ipfs/QmId multiaddrs to /ip4/.../tcp/.../p2p/QmId as the former is confusing (e.g., the issue here) and implies some relation to ipfs (which makes no sense when implementing other libp2p apps).
I'm aware of that. I'm saying that I chose to make the Cid class a subclass of Multihash, so in Java a Cid is a Multihash in the type sense (This still seems like the right thing to do given my understanding of things).
That's probably fine, for now at least. However, I can't guarantee that that'll always hold true. For example, I've considered CIDs with multiple multihashes (probably too big but still valid in theory).
We don't have a concept of peerId yet in Java so I suspect all those methods (equivalently) take MultiAddress in Java.
Switching to p2p sounds like a very good idea.