Split out from #1:

Is it worth adding concepts in addition to the identifier itself? For example, ceramic is an indexer network.

@erik-descilabs I don't really follow what you mean by indexer network, but any concept that a reader might want to know if they are wondering how dPID and DSI different seems to me a good addition.

I suspect that most readers do not want to learn more terminology like "indexer network". Perhaps you can write a brief description of the interesting angle of Ceramic that you are thinking of when you say indexer network.

@castedo Any thoughts on adding the functionality in a first column to clarify the intention behind the comparisons? If you're ok with that, a few additional points:

• While IPLD does serve as a tree structure, dPIDs are shifting to something more similar to a knowledge graph via ceramic. I don’t know if the tree structure comparison fully tracks
• The dPID contract is the alias registry. I clarified that in the table above.
• I want to clarify that Nodes is just an interface on top of the PID system and underlying IPFS repository. Not sure if the interface line compared to BDS still works, but DeSci Nodes is not responsible for tracking versioning. It just surfaces.
  • As a sidenote, the idea of more granular versioning is really interesting. I think we shied away from it to avoid the regulatory headache but I am still a fan of the concept.
• Is it worth adding concepts in addition to the identifier itself? For example, ceramic is an indexer network.
• In "Ceramic streams vs Git Histories", would it be possible to add a line about "anyone can host an IPFS node", indicating that storage doesn't rely entirely on the public network but is rather supplemented by it

Split out from #1:

In "Ceramic streams vs Git Histories", would it be possible to add a line about "anyone can host an IPFS node", indicating that storage doesn't rely entirely on the public network but is rather supplemented by it

@erik-descilabs My hunch is it will be better to link to a separate document to go into the benefits of specific tech. In some narrow cases, like a dPID is human-friendly, but a DSI is only URL-friendly, I think mentioning that benefit is a very useful quick contrast.

Regarding "anyone can host an IPFS node", I don't see that as a meaningful contrast. Anyone can host a Git repository, so why mention that anybody can host an IPFS node. I doubt it will be a productive for us to go back and forth about what exactly does "anyone" mean and what "being able to host" means. I say link to a separate doc about IPFS.

I also currently do not believe this language of "IPFS storage does not rely entirely on the public network". I doubt it will be productive to go back and forth carefully crafting language on what IPFS does or does not rely on and what Git repositories do or do not rely on. I say link to some other document talking about how awesome IPFS is.