What’s worth mentioning is that IPFS is built on top of a data model named IPLD.<p><a href="https://ipld.io/" rel="nofollow noreferrer">https://ipld.io/</a><p>If you are planning on doing your own experiments with Merkle tree and such, I can strongly recommend using IPLD as well. The IPLD project has standard libraries for a bunch of programming languages.<p>The advantage of using IPLD is that you can use regular IPFS tooling to inspect the data and make backups/restores. Regardless of your desire to share the data over IPFS.
As someone following German politics I had to read the headline twice :) Haven't seen it used without tree.<p>(Yes, the spelling is not the same, but we are talking associations, not exact science.)
Wouldn't it be simpler to use a trie over the hashes instead? It seems to me like it would have the properties desired here. I think the parent/child rule described here might actually result in some kind of trie.
I read this with great interest. Sometimes technologies come around that make me seriously wonder if I should embrace them or continue on the path I’ve already designed.<p>They include: CRDTs, PouchDB, hypercore, etc.<p>What I currently have is my own, PHP-based implementation of essentially a history of “collaborative documents that evolve through time” — with each document having one machine as a source of truth:<p><a href="https://qbix.com/platform/guide/streamsConcepts" rel="nofollow noreferrer">https://qbix.com/platform/guide/streamsConcepts</a><p>So basically, I think that syncing and CRDTs (y.js and automerge) can be excellent for collaborating on documents, but not so great for chatrooms and smart contracts / crypto where order of operations matters. For those, you can implement <i>optimistic interface updates</i> but when conflicts (rarely) arise, your interface may roll back changes it displayed. This is especially true after a netsplit.<p>I thought about using PouchDB but the thing is that CouchDB is an extra process people have to run and we want our stuff to run anywhere Wordpress does. Ditto for hypercore. These are great technologies, but it seems what we have is great for fhe very reason tht it’s in PHP - still the most widely supported commodity hosting environment in the world by far. What are the stats these days for PHP vs Node, Go etc.?
Question:since doing this requires hashing your entire tree, what are the implications of doing this hashing operation on possibly millions of entries (which I'm estimating is the scale at which comparing linearly really start being noticably slow)?<p>I'm guessing you need to choose a hashing function correctly, but is hashing 2n elements then comparing in log(n) actually that much faster than comparing in n? Evidently, with the right settings yes, or we wouldn't be here, but I'm just wondering if the hashing step doesn't actually end up costing a lot more than we think by saying "oh we just hash it"
If you are excited about these data structures you might be interested in my new database engine using prolly trees and designed to be used by React developers.<p>Blog: <a href="https://fireproof.storage/posts/from-mlops-to-point-of-sale:-merkle-proofs-and-data-locality/" rel="nofollow noreferrer">https://fireproof.storage/posts/from-mlops-to-point-of-sale:...</a><p>React hook: <a href="https://use-fireproof.com" rel="nofollow noreferrer">https://use-fireproof.com</a>
Does anyone know a good resource on how to efficiently build a Merkle tree from a big k/v store? for example, should you cache intermediate nodes?
Does anyone know how a tool like Figma or Miro handle conflict resolution or synchronization so efficiently in real-time? For example: the position of a simple colored box being manipulated by 2 or more people at the same time. Is this article even remotely relevant for such a use case?