-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IPFS addrs should use multihashes, not CIDs. #9
Comments
I assume you mean "Ipfs addrs should use Cids, not Multihashes"? And are you referring to the constructor? |
Wow, that title was a train wreck. But no, I meant multihases. The |
What about things like |
As it stands the Java constructor for a Multiaddr already takes a Multihash (which could be a Cid or not) |
It's a path. Multiaddrs are for network/process addresses.
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 |
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? |
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
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. |
The QmId part is actually just a bare base58 encoded multihash (for now). It's a direct hash of the peer's public key.
The text was updated successfully, but these errors were encountered: