json0

waves Y'all are talking about me. I was indeed on the wave team, although I joined Wave right near the end. (And then I stayed on to help opensource the whole thing.) We wrote ShareDB at Lever[1], which was in the 2012 YC batch (iirc). We wrote it to allow realtime collaborative editing in our application of all our data fields by default. I'm still really proud of that work. ShareDB primarily uses JSON-OT[2], which lets you do realtime OT over arbitrary application data. The lever team has been maintaining & improving sharedb for the last few years, which is really lovely to see as I've moved on to other projects. One nice thing about OT is that its much easier to implement. The original quilljs author (Jason Chen) wrote the rich text OT implementation. ShareDB works with any OT code (so long as operations can be JSON stringified / parse

My experience is with OT, so I can't speak for CRDT, but I can imagine it's similar. With OT, you send a na[1] (number add) operation, so this would work fine. Indeed, if you treat the number as a string, then you have a problem. [1]: https://github.com/ottypes/json0#summary-of-operations

> whereas OT is generally too complicated and unproven to offer that guarantee at all. Citation needed. I've built several production-level OT-based systems on top of ShareJS's JSON OT[1] code. The set of operations supported is guaranteed to be conflict-free and correct. We don't have AGDA proofs but we've used fuzzers to ferret out correctness bugs and its been about 2 years since a bug was found in the transform code. All in all, I'm very happy with the implementation. Meanwhile, I don't believe a more generic JSON OT / CRDT system can be made conflict-free. (Well it can be conflict-free, but you'll lose data if it is). If you support arbitrary tree-level moves, you have the User A moves x into y's children, user B moves y into x's children problem. There are simply no good ways to resolve these operations without user intervention, or

I've played with this problem on and off over the last few years. ShareDB[1] is powered by JSON OT[2], in which each change describes the meaning behind what you're trying to do. (For example, 'increment counter' is different from 'change counter from 2 to 3'. They look the same, but behave differently in the case of conflicts). Just knowing what changed often isn't enough to do proper resolution. I've spent years on and off playing with a better, faster, stronger version of the JSON OT code[1] which also supports arbitrary object reparenting. You run into problems where you really want conflicts as well. For example, given {x:{}, y:{}} user A moves x into y, and user B moves y into x. There's no good solution to resolving this without more information or conflict markers & humans. Doing this in a P2P setting is hard & interesting. Very c

I implemented/used both. Here is a "live" playground https://json8.github.io/patch/demos/apply/ for JSON Patch A few additional thoughts JSON Patch can be pretty verbose but going around that is easy https://github.com/JSON8/patch#patch-size When possible I also compare the size of the patch (packed) and the expected document. If the expected document is smaller than the patch I use the PUT verb with the document as body otherwise PATCH verb with the patch as body. Even though the spec doesn't talk about it at all, JSON Patch have the nice effect of being completely reversible (if you have the context) https://github.com/JSON8/patch#buildrevertpatch , not true for JSON Merge Patch JSON Merge Patch patches can be translated to JSON Patch easily https://github.com/JSON8/merge-patch#tojsonpatch https://github.com/JSON8/patch https://github.c