so, an unoptimized crdt? just set max set size to 1 and yolo?
Collaborative Text Editing Without CRDTs or OT
11–20 of 86 posts
Re: Collaborative Text Editing Without CRDTs or OT
#12Cool to see a write up on this! Discovered the same method years ago and also wondered why it doesn’t show up in academic literature. I implemented this in a decentralized context and as a CRDT though, so that the properties hold (commutative, idempotent and associative).
If the idea is to have an alternative to CRDT, what did you gain from building it as CRDT?
It wasn’t really that we wanted to have a CRDT per se, but as it was implemented on top of an op-based append-only log CRDT, it turned out to hold those properties, which makes it a CRDT. We wanted to have the edits to be able to arrive in any order or after delays due to network partitions (this was for a p2p network).
Re: Collaborative Text Editing Without CRDTs or OT
#13wonder if there would be a perf gain with UUIDv7
Why not just use an ever incrementing u64?
Re: Collaborative Text Editing Without CRDTs or OT
#14so, an unoptimized crdt? just set max set size to 1 and yolo?
It's very appealing as a kind of irreducible complexity. It feels close to what is actually happening and is simple hahah if like you say not optimized.
Re: Collaborative Text Editing Without CRDTs or OT
#15Is the take-home message of the post that the full complexity of CRDTs/OT is necessary only in the absence of a central server?
Re: Collaborative Text Editing Without CRDTs or OT
#16Re: Collaborative Text Editing Without CRDTs or OT
#17wonder if there would be a perf gain with UUIDv7
Why not just use an ever incrementing u64?
An incrementing u64 requires either atomic increments between concurrent clients or recalculation logic to consistently find the newly incremented ID after conflicting information syncs. UUIDs just spit out a unique ID without any complexity or associations with other clients.
Re: Collaborative Text Editing Without CRDTs or OT
#18wonder if there would be a perf gain with UUIDv7
Why not just use an ever incrementing u64?
Then you need central coordination, either a single central server containing the counter, or something like Snowflake where you have multiple counters, each assigned orthogonal blocks ahead of time (that need to coordinate with a central server).
UUIDs/ULIDs/etc are fully distributed, you can have two clients assign an ID without coordinating with ~0% of collision.
Re: Collaborative Text Editing Without CRDTs or OT
#19Does this finally solve collaborative text editing and its friends?
Such an awesome approach.
Re: Collaborative Text Editing Without CRDTs or OT
#20Surprised to see no discussion of other data structures like dicts/maps, or arrays of arbitrary type. Hopefully they'd be a straightforward extension. IME, apps need collaborative data structures more often than they need pure collaborative text editing.
The motivating examples (update validation, partial loading, higher-level operations) are interesting, but I don't see a strong case that the reason Yjs etc. lack these features is the underlying CRDT implementation, as opposed to these features being intrinsically difficult to build.