Hello everyone! I really like the ideas behind IPFS and I want to share some feedback about the design of the IPFS. The core of the problem is that CID concept is wrong in it’s current implementation. I know it sounds blunt and harsh so let me clarify: IPFS at its core claims to be a content add…

Hi, FYI, I am not an IPFS expert. One issue with your proposition is that if we use the file content id (let’s say sha-512), like you said, the blocks can be generated in multiple ways (with different encoding and different chunk size). So, let’s say I want to PIN the sha-512 of Ubuntu’s iso file,…

@simon I think their design decision was well chosen to have defaults and if everyone uses the same version of the software without touching any of the defaults, then yes the dedup works fine and it is still backward compatible with previous software’s version’s defaults I think that hoping that…

[image] ngortheone: I think that hoping that everybody should use default settings is wrong I am not hoping. For any software I use, I always use the default values unless there is really a big issue with them. Maybe it could be possible to add another layer like: there is “/ipfs/” for the…

Disclaimer: I’m not an IPFS dev! Merely an “enthusiastic user” [image] ngortheone: Convertiing CIDs is not possible without having the file on disk, so different peers can have same content under different CID’s, which fragments the network into incompatible segments or forces everyone to have…

Once a peer gets a file - it can calculate multiple hashes of the content and advertise them all. That indeed is more computationally expensive and will create more network traffic. I was just pointing out that computing N hashes for a file is much better than computing N *M hashes. Do not add…

To sum up: axiom: hashes are not convertible or reversable, that is their core property. Therefore: content hash X != content hash Y even if this is the same file. (duh) CID != content hash you can’t prove that CID == another CID without having the content locally (because CID contains …

There is another problem here that I’ve noticed, that’s also related to the goal of a “Worldwide Standard” for how IPFS content needs to work, and that is, there needs to be a content type (mime type) given at the front of the data, and hashed right along with the data. Storing files that can’t have…

[image] ngortheone: CID != content hash That is wrong. It’s more then the content hash. It also includes the hash you’re looking for. Like in my previous post, here’s the CID explorer link again: CID Inspector | IPFS that magic can quite likely be done through commands too. I’m very confuse…

To things I want to clarify, about what I said: I do realize MFS (Files in general) already do have at least a file name so the extension can be used to encode (or determine) the mime type, at least the way operating systems do, without true mime info, but just a file extension. But that’s not for…

CID concept is broken

Ecosystem and Usage

zacharywhitley January 4, 2021, 4:18pm 3

I recently posted a proposal for something that would address some of the issues you’ve mentioned Merkle tree root hash with lthash?

Topic		Replies	Views
How to calculate file/directory hash? Help	49	13509	August 1, 2024
File hash is different from original Help	28	2170	September 16, 2020
Two IPFS addresses for one file - how this happened? Help	5	163	October 24, 2025
Is there an API method to get the IPFS hash of a file? Help	8	1347	May 17, 2023
Should we profile CIDs? Protocol	51	1699	March 16, 2026

CID concept is broken

Related topics