Hi all! I’m from the Braid group (braid dot org), and was part of the “Faster CRDTs” project with josephg mentioned above.
I’m pleased to meet you guys! We work on making state synchronization interoperable, by connecting with other projects and generalizing our approaches into common protocols.
Noel showed me a demo of this system in the SolidOS meeting this morning. It’s sweet! I have a suggestion on the architecture.
I’m seeing the following stack of abstractions:
State (of the recipe) <-
------------------------------ \
CRDT history + metastate |
------------------------------ notifications
RDF ^
------------------------------ /
HTTP (state transfer protocol) --
There’s a deep mismatch here inherited from HTTP. HTTP is a state transfer protocol (consider that REST stands for REpresentational State Transfer), but we are trying to do state synchronization over it. So we end up expressing the CRDT history itself as state, on top of RDF, and then each client computes its current state from that RDF state. We have recursive state, with state computed from state, and state at both the top and bottom of the stack.
Moreover, since HTTP itself doesn’t provide any subscription notification system, we have to use out-of-band solid notifications, which tell the client to re-fetch the state using the HTTP state transfer protocol. This requires extra roundtrips, and ends up more convoluted and messy than if we solve state synchronization in HTTP directly.
If we add CRDT+Notifications into HTTP directly, we can simplify the architecture quite a bit:
State of the recipe
------------------------
RDF
------------------------
HTTP with CRDT history + Notifications (state sync protocol)
This reduces round trips, simplifies the stack, and also makes it more general, because the synchronization features (versioning, subscriptions, patches, and CRDT/OT semantics) can interoperate beyond Solid, and work for any content-type
, not just RDF.
We’re extending HTTP in this way with the Braid-HTTP protocol. I think we could add some powerful features to Solid with Braid-HTTP, and do it in a general way that interoperates with other systems too. Solid is uniquely poised to benefit from this work, because it’s built on top of HTTP, and also seeks interoperable standardized solutions. I think our projects are very complementary.