Editing, CRDTs, etc

[TheKnarf]

Currently the dataflow only goes one way, from a textfile to the server. There are no editing capabilities in the server. This is similar to tools like mdx-deck and revealjs. However it would be interesting to support a more Google Slides like interface where you can make live edits. This poses two interesting challanges:

1. Syncronozition between the textfile and server. I would like to preserve the feature that you can easily create a presentation by simply editing a textfile in your prefered text editor. If a file is open in both your text editor and the server at the same time this might introduce conflicts if you try to switch back and forth between the two ways of editing. There are a few ways of solving this:

1.1. Lockfiles / swapfiles. While editing the textfile one might want to lock editing of it in some way so that other applications can't edit it at the same time. This could work but is also the least ergonomic way of solving this issue.

1.2. Do everything through Git. Git supports multiple people / services editing a file at the same time in their own branch. Merging branches are however usually done manually and can introduce conflicts. For local editing with one user switching between applications, unless this can be automated, then its hardly any more ergonomic than locking the file.

1.3. CRDT's and Operational Transformation. These techniques are interesting but require to store the data and events in a specialized way, and such are incompatible with simple markdown / mdx documents. One solution might be to store the CRDT/OT data in a seperate file, as some kind of hybrid "swapfile" solution. Still how to sync changes from the markdown into the CRDT/OT is an open question.

2. The second challange is syncing edits between several webbrowser based clients all making edits at the same time. This is an easier problem to solve than the first one. As we here can much more easily spin up some kind of CRDT/OT solution that can keep track of state and sync between clients.

2.2. Automerge and Peritext are both interesting project to learn from. They do not allow you to setup a schema before hand, nor select which CRDT merging strategies you would like to use. I think its important as a software developer to control the semantics of the mergs by choosing which CRDT strategies you wish to use for the application. As such Automerge and Peritext becomes interesting implementations to learn from, but not libraries that are applicable to use directly.

2.3. However for prototyping one might need to pick a less idealized solution and actually go for using Automerge to simply get up a working version. By writing code so that are able to seperate the concerns in codebase, one might at a later point replace Automerge with another solution.