# Collaborative Software Created: [[2024_08_18]] 11:46 Tags: Since, I've just started working at Tiptap (YC S24) in April of 2024, I've now taken notice just how much of a market there is for collaborative software. At my previous company, AgileMD (YC S11), we had made attempts at making a collaborative experience for our flowcharting tool but failed miserably because of the failure modes involved in collaborative software. ## Going from single-player to multi-player Collaborative software fundamentally is a question of data structures and how you represent them in your system. Given that everything is a tradeoff, you have to which sorts of tradeoffs you are willing to make. To start simply, take a data structure like this: ```ts type Article = { name: string; publishedAt: Date; content: string; } ``` Let's say that two people are trying to edit this data structure (e.g. an editor and a writer). By default, in most REST style APIs that people would build for this sort of a system, it would be last-write-wins. This means that whoever happened to submit last, is what the content will result in, like this: ![[collaborative-software-lww.excalidraw.svg]] In this case, it does not matter what user A updating the name to because user B overwrote with their value. While this may be okay for something like an article name, it is probably unacceptable for something like the article's content. No one wants to have typed up a bunch of work only to have their work lost because another person submitted a change without that work being saved. ### Solutions You may try to come up with your own super inventive algorithm (when at AgileMD I personally tried a read before you write approach that failed miserably), and maybe that might work for the kind of software you are making. But, in essence you will be duplicating the life work of computer scientists like Kevin Jahns and Martin Kleppman who make the two best open source solutions available for this right now [Yjs](https://docs.yjs.dev/) and [Automerge](https://automerge.org/docs/hello/). The core of the work that they perform is by using algorithms known as [CRDTs](https://automerge.org/docs/glossary/#crdts) (Conflict-Free Replicated Data Type) they are able to store the data in such a way that conflicts between edits within a structure (e.g. a string of text) can be resolved automatically and deterministically. This allows your application to converge on states rather than just completely erasing a collaborators work. These data structures are quite complex, and for performance reasons are often represented in a binary format when stored. This is a departure from a world in which everyone is representing everything as JSON, but if you can manage past that hurdle, you can enable a modern user experience that your users expect. ## References -