I think CRDTs are super cool, and likely future of offline-first experiences. My main issue with Taskpaper documents in iCloud drive has been the awful conflict resolution experience, and would love an industry standard way of doing the merges automatically, in a syntax-aware way.<p>Funny you should post this article now, as I'm just getting ready to start on this work myself, would love recommendations about how to do this automatic conflict resolution on semi-structured text files if anyone has some!
I like the approach of using differential synchronization at the edges of a CRDT system. It seems like this approach can work well for plaintext data, or data easily reduced to a fixed set of plaintext fields.<p>For more advanced formats - like a tree structure document - I’m intimidated by the problem of computing a good semantic diff from the plaintext format, and how to apply that semantic diff to the CRDT format. Adding an `id` to every node in the tree is helpful for this purpose - but that makes it harder to write such documents by hand in plaintext.<p>Have you encountered any troubles with weird diffs that put documents into invalid states? For example, plaintext updates that somehow merge in a way that breaks the MDX or JS syntax? Do you have or foresee having a “resolve merge conflicts” flow?
This is a fantastic direction. It's interesting to me that you would rather revision control be implemented outside of this replication topology in something like git and that the interface between tools is strictly files rather than the CRDT events themselves. Integrating other applications in the CRDT event stream and maintaining the stream as the revision history would seem more efficient, less error-prone, and more open. Is it an eventual goal to expose something like this?
This is mind blowing stuff. I was skeptical that you could use the browser effectively as an intermediary to the file system, and that CRDTs would work reasonably well on files, but they seem to have overcome both obstacles. I’m curious, how do you envision this approach working with version control systems? What would it mean to “explore” a branch of a git repository, for example? Would that overwrite the global version of the file system?
I'm excited about this work. Traditionally it's been hard to bridge local files and cloud documents, meaning that cloud data tends to stay siloed in specific editing UIs. This seems like the right first step towards letting traditional file-based editors work with realtime-collaborative cloud data.<p>Ultimately, in the long term, I think the filesystem probably provides the wrong abstraction for this use case though. The API we really need is "make these changes", (w/ changes represented thoughtfully in a mergeable way) not "here's the new final state." For now, diffing filesystem states is a reasonable workaround.
Great write-up! I was wondering, do you run into any issues with corrupted formatting, like what is described in Peritext?<p><a href="https://www.inkandswitch.com/peritext/" rel="nofollow">https://www.inkandswitch.com/peritext/</a>
I've been using this for a bit and it's incredibly cool to write plain markdown files VS Code and see them reflected immediately online. Well done + exciting step forward in Bring Your Own Client.
File system access is going to make some amazing things possible. With that plus service workers, Web is finally catching up to native.<p>I'm glad to see that other browsers(Except FF) have it.
The demo is incredible and really cool to see you supporting the open source contributors behind the libraries you are using. Is it possible to handle going offline?