Hacker News Reader

Comment by dnautics | Hacker News Reader

We just got CRDTs for generic textual documents! yeesh. Patience!

code has generic textual components -- like comments -- plus tree-like elements -- so it's arguably more complex. Furthermore, one expects automatically merging conflicting content to often have to be resolved because even a merge + a sophisticated node-based merging strategy will fail to capture effectful intents. However, i am excited to see tooling where, for example competing merges get run through a trichotomy (A only, B only, A + B) to see which branch satisfies the most number of tests... And then suggests the resolution accordingly.

View on HN

In terms of generic textual documents, do you have a link? The only thing that comes to mind is Pijul:

https://pijul.org/

I also found peritext:

https://www.inkandswitch.com/peritext/

There's also yjs:

https://github.com/yjs/yjs

oh I think peritext is "automerge" with formatting? which is referenced by OP. OP calls it a "json-based CRDT", which is true for automerge, but that description may be confusing: JSON is the "storage/(transport?) datastructure", the "materialized datastructure" for automerge is plain text. Note that one of the creators of peritext (martin kleppmann) is also creator of automerge.

We just got CRDTs for generic textual documents! yeesh. Patience!

Really? Link?

automerge? it's in OP

Merging text documents automatically can easily be shown to produce garbage results; it is not conflict-free.

If it did not have this problem, then that would give use the solution for syntax, right? Syntax trees can be turned into text documents. Oh, and those are a CRDT: and we have automerge. QED.

Conflict-free refers to the datatype under the specific criterion of distributed consensus, it says nothing about the semantic meaning of the resulting data. You can take ANY CRDT and assign an arbitrary semantic meaning to it that induces a conflict, that does not suddenly make it conflict-free.

Point is we now have CRDTs for free text that are reasonably useful because most of the transformations that are encoded map to human expectations for resolution.

OK, so without the semantics, the data is syntax.

So there we have the CRDT for syntax; it's every CRDT.

Every type has shapes, which are syntax, and those are invariant, as are some other constraints which can be shoehorned into syntax. E.g we can make it a matter of syntax, not semantics, that in {3, "foo", bar, 3.14}, the 3 must be the count of the remaining elements.

Reply on news.ycombinator.com