mweidner

> This doesn’t work for collaborative software.

Is the issue the lack of real-time updates? In principle, you could work around that using a separate WebRTC channel for live updates, with the slower Dropbox sync serving as the source-of-truth. (It does indeed take >=5 seconds for Dropbox to sync a collaborative app in the way the author describes, in my experience.)

The demo they show uses the Quill rich-text editor, which handles block elements analogously to text attributes: a block's type is determined by the attributes on its trailing newline. E.g., for a block that is part of an ordered list, the newline's format is `{ list: "ordered" }`.

https://quilljs.com/docs/delta/#line-formatting

The product page is clearer (https://skiff.com/mail):

> All emails between Skiff users are end-to-end encrypted, including both subject and contents. External mail is encrypted with your keys on receipt, keeping it private.

I believe individual fields are last-writer-wins. Fancier CRDTs like text/lists are not directly supported, but I found that you can layer them on top: https://github.com/mweidner037/list-demos/tree/master/tripli...

In my experience, this depends a lot more on the implementation than the CRDT algorithm. If you implement Causal Trees directly (as a tree with one node per char), it will be tolerably fast but use a lot of memory + storage. If you instead group chars into "runs" of sequentially-inserted chars and only store one Causal Tree node per run, it should be quite efficient.

Yjs (a widely used text CRDT) describes these sort of opts here: https://blog.kevinjahns.de/are-crdts-suitable-for-shared-edi... For a different tree-based CRDT, I did a head-to-head comparison of implementations that use a node-per-char (Fugue Simple) vs runs (Fugue), with results in Section 5 of this paper: https://arxiv.org/abs/2305.00583

Another name for Causal Trees is "RGA" (Replicated Growable Array). They are ~identical algorithms that were published concurrently. E.g., Automerge uses RGA (https://automerge.org/docs/documents/#lists).

> Opaque State: [...] You can’t inspect your model represented by the CRDT without using the CRDT library to decode the blob, and you can’t just store the underlying model state because the CRDT needs its change history also. You’re left with an opaque blob of data in your database.

As someone who works on a CRDT library with opaque state [1], I agree that this is a big barrier to adoption. Features like partial loading, per-paragraph permissions, and accept/reject suggestions seem pretty easy to implement if each text char is just a row in your server's DB, but I would have trouble implementing them on top of e.g. Yjs.

For text editing, one idea is to separate the CRDT "positions" from the text itself, which you can then store as a map (position -> char) in your own data structures. I've made a simple (but inefficient) library along these lines [2] and would be interested in ideas for further development.

[1] Collabs - https://collabs.readthedocs.io

[2] position-strings - https://www.npmjs.com/package/position-strings

Early papers (e.g. https://inria.hal.science/inria-00555588) use C=Convergent for state-based CRDTs and C=Commutative for op-based CRDTs. Nowadays it is usually C=Conflict-free for all variants (e.g. https://en.wikipedia.org/wiki/CRDT).

You could add to the confusion by using C=Collaborative. (I personally prefer "collaborative data structures" for the more general concept of data structures that can be edited on multiple devices; CRDT is a mouthful and now also a buzzword.)

Same here. There is even a new $10/mo variant that is still plenty for me.

One idea is just to use fewer random bits in peerIDs. Yjs (https://docs.yjs.dev/) gets away with just 32 random bits. If you compromise and use 64 random bits, then even a very popular doc with 1 million lifetime peerIDs will have a < 10^-7 lifetime probability of collision.