Consider using yjs / y-crdt for document-related commits

[joepio]

Atomic Commits describe how resources update. I'm happy with part of it, but I'm also having some doubts:

• Merging isn't clear yet and requires an implementation (at very least in the server)
• Atomic Commits doesn't have a formal proof of eventual consistency
• No support for inserts / deletions in text, only replace an entire k/v pair.
• No support for formatting changes
• No cursor positioning
• No great front-end

Doing all these things takes a lot of time. It might be nice if we could just use something like Yjs or Gun to deal with all the state updates.

However, there are some things I still want to keep, ideally:

• It would be nice if the changes themselves are understandable. Atomic Commits are pretty simple Yjs seems pretty complicated, which means the user is forced to use a library, and the libraries take a lot of time to build.
• signatures are cool, because we get audit logs
• I want to persist the changes and allow re-applying them to build a version history

What would it mean to use yjs in atomic-server

• Add a yjs action to Commits, like we have set and delete.
• We keep a yjs document in the front-end for every resource. The set and delete and insert functions utilise these yjs methods. Calling .save pushes the state vector to the server in a commit.
• yrs parses the yjs StateVector and updates the state in AtomicServer.
• I'm a little concerned as to how big these changes will be. Maybe we should not persist every state/transaction.
• If we switch to NextGraph, we might skip this because it already has a text editor.
• We could replace our editor with blocknote, which also uses yjs Fancy markdown / document editor - #741

[joepio]

@colelawrence had some interesting ideas about this:

• We might consider a blob datatype. The property mimetype can then describe how these are interpreted.
• We can add operations to Commits that users can define, e.g. YjsAction