3 ms·
Yup, already doing that in the betas. Thats what I'm referring to as the beginnings of a "content addressable store" in the article. In the closed source fork
by nikisweeting 2y ago
Yup, already doing that in the betas. Thats what I'm referring to as the beginnings of a "content addressable store" in the article.
In the closed source fork we currently store a merkle tree summary of each dir in a dotfile containing the sha256 and blake3 hash of all entries / subdirs. When a result is "sealed" the summary is generated, and the final salted hash can be submitted to Solana or ETH or some other network to attest to the time of capture and the content. (That part is coming via a plugin later)
- orblivion 2y agoWow that's great!
- zvr 2y agoYou might be interested in taking a look at SWHID (Software Hash IDentifiers), which defines a way (on its way to become an ISO standard) to reference files and directories with content-based identifiers, like swh:1:dir:d198bc9d7a6bcf6db04f476d29314f157507d505. Yes, it uses Merkle trees for filesystem hierarchy. https://www.swhid.org/specification/v1.1/5.Core_identifiers/ https://www.swhid.org/specification/v1.1/5.Core_identifiers/