I don’t recall CRDTs (Conflict-free Replicated Data Types) being mentioned here before, and am interested to hear if people think they could be useful for Solid.
I wrote the following in response to @NoelDeMartin’s post raising an issue with performance when an LDP container holds hundreds of documents. But I think CRDTs merit a topic of their own.
An alternative which I think would be interesting to explore for Solid is local-first using CRDTs. It’s a bit like offline-first, but peer to peer rather than syncing with a central server, so each participant has a local copy of a CRDT type document which they can edit, and changes are automatically synced by exchanging edits between peers. By implementing documents as CRDTs the merging changes is completely automatic and guaranteed to produce the same result in every copy.
This tech was probably a bit late to be considered originally for Solid but is now coming of age and could be another alternative to the downsides of a server based model.
So it’s not a quick fix - more an opportunity to rethink - and probably not immediately helpful, sorry! I’ve been looking into it recently, so I could start a topic of anyone is interested, or provide links etc.
Maidsafe have begun to switch over to using CRDTs within SAFE network for individual data types, and I’m looking at using it for a self replicating filesystem that could be mounted using FUSE. These are not local-first applications at this time, but a way to ensure the network data types can be replicated for redundancy, updated arbitrarily, and remain conflict free. I am still thinking about local first though, because it’s a promising way to implement collaborative applications in its own right, and could well solve the kind of problems we are seeing with Solid because of its server based model. Lots of issues just disappear when you eliminate servers.
For anyone who wants to follow up on CRDTs, here are a few links.
- CRDTs: The Hard Parts — Martin Kleppmann’s talks (link). See this post for notes about this talk with time stamps.
-
A highly-available move operation for replicated trees and distributed filesystems, Kleppmann et al, 2020 (move-op.pdf)
- Code data etc related to the move-op paper (trvedata/move-op)
- Local-first software: You own your data, in spite of the cloud (link)
- Rust implementation of automerge (automerge/automerge-rs)
I particularly recommend Martin Kleppmann’s video presentation (I made notes from it which give times for different aspects, key slides and so on here).