It's the Byzantine Fault Tolerant part of this that is particularly innovative and based on Kleppmanns most recent work. I believe it solves the issue of either malicious actors in the networks modifying others transactions, spoofing them, or the messages being modified by third parties ("outside" the network) who have MITM the connection. These are really great problems to solve.<p>However, when I was experimenting with CRDTs a while back, it seemed to me the other big issue is where multiple transactions from different users combine to create an invalid state. Most CRDT toolkits are aiming for a combination of a JSON like type structure, with the addition on specific structures for rich text. The JSON structures for general purpose data, and those for rich text as that is the most common current use case. These sort of general purpose CRDTs don't have a way to handle, say, the maximum length of an array/string, or minimum and maximum values for a number. They leave this to the application using the toolkit.<p>For the Yjs + ProseMirror system, effectively the CRDTs are resolved outside of ProseMirror. Thats useful as they can be combined/resolved on the server without a ProseMirror instance running. However there is a strong possibility that the resulting structure is no longer valid for your ProseMirror Schema, this is currently handled by ProseMirror throwing away the invalid parts of the document when it loads.<p>What I think is needed is a Schema system that is a layer either on top of these toolkits, or as part of them, that provides rules and conflict resolution. So there is a way to specify the maximum length of an array/string, or what the maximum value of a number is. Effectively generic CRDTs that have an understanding of developer supplied rules and bounds.<p>The "maximum length" is an interesting one, as depending on the order of transactions you could end up with a different result.
> I write this blog post mostly as a note to my past self, distilling a lot of what I’ve learned since into a blog post I wish I had read before going in<p>The best kind of blog post!
For people like me:<p>BFT - Byzantine Fault Tolerant [0]<p>CRDT - Conflict-free Replicated Data Type [1]<p>[0] <a href="https://en.wikipedia.org/wiki/Byzantine_fault" rel="nofollow">https://en.wikipedia.org/wiki/Byzantine_fault</a><p>[1] <a href="https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type" rel="nofollow">https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...</a>
From the article, this appears to be an implementation of Making CRDTs Byzantine Fault Tolerant [0] in Rust [1].<p>[0]: <a href="https://martin.kleppmann.com/papers/bft-crdt-papoc22.pdf" rel="nofollow">https://martin.kleppmann.com/papers/bft-crdt-papoc22.pdf</a><p>[1]: <a href="https://github.com/jackyzha0/bft-json-crdt" rel="nofollow">https://github.com/jackyzha0/bft-json-crdt</a>
I'm quite surprised by the [benchmarks versus Automerge JS & Rust](<a href="https://github.com/jackyzha0/bft-json-crdt#benchmarks" rel="nofollow">https://github.com/jackyzha0/bft-json-crdt#benchmarks</a>) when it comes to memory:<p>> Ours (Basic) 27.6MB<p>> Ours (BFT) 59.5MB<p>> Automerge (Rust) 232.5MB<p>I would expect adding the public key tracking to use more memory; I wonder how Automerge is spending so much more memory. Possibly on a bunch of internal caches or memoization that give the order-of-magnitude improvement in speed?<p>> Ops: 100k<p>> Ours (Basic) 9.321s<p>> Ours (BFT) 38.842s<p>> Automerge (Rust) 0.597s