Possible use within a document editor

[matthew-carroll]

I wanted to drop by and say hi. I'm investigating the use of CRDTs to power offline mode and multiplayer mode for Super Editor, which is a document editing toolkit for Flutter, which I lead: https://github.com/superlistapp/super_editor

I was wondering, do you have any guidance for working towards that goal? Our team is new to CRDTs - we've done a bit of reading and watched some presentations about the concept, but we're still very new.

Also, please let me know if you'd like to help with such an integration.

[cachapa]

Sorry I missed your message back in August, I guess it got lost in the shuffle of vacation.

Realtime multiplayer text editing is a complex topic that I haven't look into much myself.

My understanding is that CRDTs can definitely be used for this, and I believe this package is flexible enough to accommodate it but it will only handle the node insertion and synchronization for you.

A lot of effort still needs to be put into finding the right balance between tracking all input actions vs. letting the dataset grow to become too large to be useful.

[matthew-carroll]

Tagging some team members for visibility: @angelosilvestre, @suragch, @rutvik110

[matthew-carroll]

@cachapa based on your experience, do you think that CRDTs modeled for text editing would be a composition of smaller pieces that come from this package? Or would you expect that we need to create entirely new data types specifically for that purpose?

My initial research suggests that later, but I'm curious about your perspective as someone who has already implemented a collection of CRDTs.

[cachapa]

As I said above I've not gotten deep enough into this topic to say for sure, but the current implementation does support the most fundamental data types (ints, doubles, strings) which would in theory allow you to combine them to create more complex ones.

My concern would naturally be performance, as you'd probably want to make querying your structures very quick, which would probably mean your types might have to be broken down into their components in the underlying CRDT store.

An instance of this can be seen in the table structure for sql_crdt, which stores the node id in its own column despite it already being part of the HLC for the same entry. It's done simply because we need to run SQL queries on the node id which is a lot faster if it's stored separately: https://github.com/cachapa/sql_crdt/blob/master/lib/src/crdt_executor.dart#L87

I'm interested in this topic though, if you do find opportunities for improving this library to support your use case I'd be happy to explore extending it.