Skip to content

Instantly share code, notes, and snippets.

@0xdevalias

0xdevalias/editor-frameworks-and-collaborative-editing-tech.md

Last active January 8, 2025 04:17
Show Gist options
  • Save 0xdevalias/2fc3d66875dcc76d5408ce324824deab to your computer and use it in GitHub Desktop.
Save 0xdevalias/2fc3d66875dcc76d5408ce324824deab to your computer and use it in GitHub Desktop.
Download ZIP
Some notes on editor frameworks (eg. Monaco, Lexical, Codemirror, etc) + collaborative editing/conflict resolution technologies (eg. OT, CRDT, etc)
Raw
editor-frameworks-and-collaborative-editing-tech.md

Editor Frameworks and Collaborative Editing/Conflict Resolution Tech

Some notes on editor frameworks (eg. Monaco, Lexical, Codemirror, etc) + collaborative editing/conflict resolution technologies (eg. OT, CRDT, etc)

Table of Contents

Editor Frameworks

CodeMirror

Lexical

  • https://lexical.dev/

    • An extensible text editor framework that does things differently

    • https://playground.lexical.dev/

      • Playground

      • The playground is a demo environment built with @lexical/react.

    • https://lexical.dev/docs/intro

      • Docs

    • https://lexical.dev/docs/api/

      • Docs - API

    • https://github.com/facebook/lexical

      • Lexical

      • Lexical is an extensible text editor framework that provides excellent reliability, accessibility and performance.

      • Lexical is an extensible JavaScript web text-editor framework with an emphasis on reliability, accessibility, and performance. Lexical aims to provide a best-in-class developer experience, so you can easily prototype and build features with confidence. Combined with a highly extensible architecture, Lexical allows developers to create unique text editing experiences that scale in size and functionality.

      • https://github.com/facebook/lexical#getting-started-with-react

        • Getting started with React

        • Note: Lexical is not only limited to React. Lexical can support any underlying DOM based library once bindings for that library have been created.

      • https://github.com/facebook/lexical#lexical-is-a-framework

        • Lexical is a framework The core of Lexical is a dependency-free text editor framework that allows developers to build powerful, simple and complex, editor surfaces.

      • https://github.com/facebook/lexical#working-with-lexical

        • Working with Lexical This section covers how to use Lexical, independently of any framework or library. For those intending to use Lexical in their React applications, it's advisable to check out the source-code for the hooks that are shipped in @lexical/react.

    • https://github.com/facebook/lexical-ios

      • Lexical iOS An extensible text editor/renderer written in Swift, built on top of TextKit, and sharing a philosophy and API with Lexical JavaScript.

      • Lexical iOS is an extensible text editor framework that integrates the APIs and philosophies from Lexical Web with a Swift API built on top of TextKit.

Monaco Editor

TinyMCE

Collaborative Editing / Conflict Resolution

General

  • https://en.wikipedia.org/wiki/Collaborative_real-time_editor

    • A collaborative real-time editor is a type of collaborative software or web application which enables real-time collaborative editing, simultaneous editing, or live editing of the same digital document, computer file or cloud-stored data – such as an online spreadsheet, word processing document, database or presentation – at the same time by different users on different computers or mobile devices, with automatic and nearly instantaneous merging of their edits.

      Real-time editing performs automatic, periodic, often nearly instantaneous synchronization of edits of all online users as they edit the document on their own device. This is designed to avoid or minimize edit conflicts.

    • https://en.wikipedia.org/wiki/Collaborative_real-time_editor#Technical_challenges

      • Technical challenges

      • The challenge of real-time collaborative editing is to figure out exactly how to apply edits from remote users, which were originally created in versions of the document that never existed locally, and which may conflict with the user's own local edits.

      • a basic collaborative editor can also be created in a client–server model. In a client–server scenario, one of the editor instances is assigned the role of collaboration server when the document is opened. This server ensures that other editors are kept in sync by determining network latency and acting as a time synchronization server. The server receives timestamped notifications of changes made to the document by other users. It determines how those changes should affect its local copy, and broadcasts its changes to the collaboration pool. In some models, the changes are not reflected on a client until an official response is returned from the server, even if those changes were made locally.

        This approach, while significantly less powerful, allows for basic collaboration at a relatively low cost.

Operational Transformation

  • https://en.wikipedia.org/wiki/Operational_transformation

    • Operational transformation (OT) is a technology for supporting a range of collaboration functionalities in advanced collaborative software systems. OT was originally invented for consistency maintenance and concurrency control in collaborative editing of plain text documents. Its capabilities have been extended and its applications expanded to include group undo, locking, conflict resolution, operation notification and compression, group-awareness, HTML/XML and tree-structured document editing, collaborative office productivity tools, application-sharing, and collaborative computer-aided media design tools. In 2009 OT was adopted as a core technique behind the collaboration features in Apache Wave and Google Docs.

    • https://en.wikipedia.org/wiki/Operational_transformation#System_architecture

      • Collaboration systems utilizing Operational Transformations typically use replicated document storage, where each client has their own copy of the document; clients operate on their local copies in a lock-free, non-blocking manner, and the changes are then propagated to the rest of the clients; this ensures the client high responsiveness in an otherwise high-latency environment such as the Internet. When a client receives the changes propagated from another client, it typically transforms the changes before executing them; the transformation ensures that application-dependent consistency criteria (invariants) are maintained by all sites. This mode of operation results in a system particularly suited for implementing collaboration features, like simultaneous document editing, in a high-latency environment such as the web.

    • An alternative to OT is differential synchronization.

      Another alternative to OT is using sequence types of conflict-free replicated data type.

Conflict-free Replicated Data Type (CRDT)

  • https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type

    • In distributed computing, a conflict-free replicated data type (CRDT) is a data structure that is replicated across multiple computers in a network, with the following features:

      • The application can update any replica independently, concurrently and without coordinating with other replicas.
      • An algorithm (itself part of the data type) automatically resolves any inconsistencies that might occur.
      • Although replicas may have different state at any particular point in time, they are guaranteed to eventually converge.

      The CRDT concept was formally defined in 2011 by Marc Shapiro, Nuno Preguiça, Carlos Baquero and Marek Zawirski. Development was initially motivated by collaborative text editing and mobile computing. CRDTs have also been used in online chat systems, online gambling, and in the SoundCloud audio distribution platform. The NoSQL distributed databases Redis, Riak and Cosmos DB have CRDT data types.

    • Background Concurrent updates to multiple replicas of the same data, without coordination between the computers hosting the replicas, can result in inconsistencies between the replicas, which in the general case may not be resolvable. Restoring consistency and data integrity when there are conflicts between updates may require some or all of the updates to be entirely or partially dropped.

      Accordingly, much of distributed computing focuses on the problem of how to prevent concurrent updates to replicated data. But another possible approach is optimistic replication, where all concurrent updates are allowed to go through, with inconsistencies possibly created, and the results are merged or "resolved" later. In this approach, consistency between the replicas is eventually re-established via "merges" of differing replicas. While optimistic replication might not work in the general case, there is a significant and practically useful class of data structures, CRDTs, where it does work — where it is always possible to merge or resolve concurrent updates on different replicas of the data structure without conflicts. This makes CRDTs ideal for optimistic replication.

      As an example, a one-way Boolean event flag is a trivial CRDT: one bit, with a value of true or false. True means some particular event has occurred at least once. False means the event has not occurred. Once set to true, the flag cannot be set back to false (an event having occurred cannot un-occur). The resolution method is "true wins": when merging a replica where the flag is true (that replica has observed the event), and another one where the flag is false (that replica hasn't observed the event), the resolved result is true — the event has been observed.

    • https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type#Types_of_CRDTs

      • There are two approaches to CRDTs, both of which can provide strong eventual consistency: state-based CRDTs and operation-based CRDTs

      • State-based CRDTs (also called convergent replicated data types, or CvRDTs) are defined by two types, a type for local states and a type for actions on the state, together with three functions: A function to produce an initial state, a merge function of states, and a function to apply an action to update a state. State-based CRDTs simply send their full local state to other replicas on every update, where the received new states is then merged into the local state. To ensure eventual convergence the functions should fulfill the following properties: The merge function should compute the join for any pair of replica states, and should form a semilattice with the initial state as the neutral element. In particular this means, that the merge function must be commutative, associative, and idempotent. The intuition behind commutativity, associativity and idempotence is that these properties are used to make the CRDT invariant under package re-ordering and duplication. Futhermore, the update function must be monotone with regard to the partial order defined by said semilattice.

        Delta state CRDTs (or simply Delta CRDTs) are optimized state-based CRDTs where only recently applied changes to a state are disseminated instead of the entire state.

      • Operation-based CRDTs (also called commutative replicated data types, or CmRDTs) are defined without a merge function. Instead of transmitting states, the update actions are transmitted directly to replicas and applied. For example, a operations-based CRDT of a single integer might broadcast the operations (+10) or (−20). The application of operations should still be commutative and associative. However, instead of requiring that application of operations is idempotent, stronger assumptions on the communications infrastructure are expected -- all that operations are must be delivered to the other replicas without duplication.

        Pure operation-based CRDTs are a variant of operation-based CRDTs that reduces the metadata size.

      • The two alternatives are theoretically equivalent, as each can emulate the other. However, there are practical differences. State-based CRDTs are often simpler to design and to implement; their only requirement from the communication substrate is some kind of gossip protocol. Their drawback is that the entire state of every CRDT must be transmitted eventually to every other replica, which may be costly. In contrast, operation-based CRDTs transmit only the update operations, which are typically small. However, operation-based CRDTs require guarantees from the communication middleware; that the operations are not dropped or duplicated when transmitted to the other replicas, and that they are delivered in causal order.

        While operations-based CRDTs place more requirements on the protocol for transmitting operations between replicas, they use less bandwidth than state-based CRDTs when the number of transactions is small in comparison to the size of internal state. However, since the state-based CRDT merge function is associative, merging with the state of some replica yields all previous updates to that replica. Gossip protocols work well for propagating state-based CRDT state to other replicas while reducing network use and handling topology changes.

  • https://crdt.tech/

    • A Conflict-free Replicated Data Type (CRDT) is a data structure that simplifies distributed data storage systems and multi-user applications.

      In many systems, copies of some data need to be stored on multiple computers (known as replicas). Examples of such systems include:

      • Mobile apps that store data on the local device, and that need to sync that data to other devices belonging to the same user (such as calendars, notes, contacts, or reminders);
      • Distributed databases, which maintain multiple replicas of the data (in the same datacenter or in different locations) so that the system continues working correctly if some of the replicas are offline;
      • Collaboration software, such as Google Docs, Trello, Figma, or many others, in which several users can concurrently make changes to the same file or data;
      • Large-scale data storage and processing systems, which replicate data in order to achieve global scalability.

      All such systems need to deal with the fact that the data may be concurrently modified on different replicas. Broadly speaking, there are two possible ways of dealing with such data modifications:

      • Strongly consistent replication:
        • In this model, the replicas coordinate with each other to decide when and how to apply the modifications. This approach enables strong consistency models such as serializable transactions and linearizability. However, waiting for this coordination reduces the performance of these systems; moreover, the CAP theorem tells us that it is impossible to make any data changes on a replica while it is disconnected from the rest of the system (e.g. due to a network partition, or because it is a mobile device with intermittent connectivity).
      • Optimistic replication:
        • In this model, users may modify the data on any replica independently of any other replica, even if the replica is offline or disconnected from the others. This approach enables maximum performance and availability, but it can lead to conflicts when multiple clients or users concurrently modify the same piece of data. These conflicts then need to be resolved when the replicas communicate with each other.

      Conflict-free Replicated Data Types (CRDTs) are used in systems with optimistic replication, where they take care of conflict resolution. CRDTs ensure that, no matter what data modifications are made on different replicas, the data can always be merged into a consistent state. This merge is performed automatically by the CRDT, without requiring any special conflict resolution code or user intervention.

      Moreover, an important characteristic of CRDTs is that they support decentralised operation: they do not assume the use of a single server, so they can be used in peer-to-peer networks and other decentralised settings. In this regard CRDTs differ from the algorithms used by Google Docs, Trello, and Figma, which require all communication between users to flow via a server.

    • https://crdt.tech/resources

      • CRDT Resources

    • https://crdt.tech/implementations
    • https://github.com/ept/crdt-website

      • Source of the crdt.tech website

Differential Synchronization

  • https://neil.fraser.name/writing/sync/

    • Differential Synchronization by Neil Fraser, January 2009

    • Keeping two or more copies of the same document synchronized with each other in real-time is a complex challenge. This paper describes the differential synchronization algorithm. Differential synchronization offers scalability, fault-tolerance, and responsive collaborative editing across an unreliable network.

    • Conventional Strategies The three most common approaches to synchronization are ownership, event passing and three-way merges. These methods are conceptually simple, but all have drawbacks.

      Locking is the simplest technique. In its most basic form, a shared document may only be edited by one user at a time. A familiar example is Microsoft Word's behaviour when opening a document on a networked drive. The first user to open the document has global write access, while all others have read-only access. This does not allow for real-time collaboration by multiple users.

      A refinement would be to dynamically lock and release subsections of the document. However this still prevents close collaboration. Subsection locking also restricts editability when the document is small. Furthermore, support for fine-grained locking would have to be explicitly built into the application. Finally, locking is ill-suited for operation in environments with unreliable connectivity since the lock or unlock signals can get lost, leaving no owner.

      Event passing is also a simple technique. It relies on capturing all user actions and mirroring them across the network to other users. Algorithms based on Operation Transformation are currently popular for implementing edit-based collaborative systems. Obtaining a snapshot of the state is usually trivial, but capturing edits is a different matter altogether. A practical challenge with event passing synchronization is that all user actions must be captured. Obvious ones include typing, but edits such as cut, paste, drag, drop, replacements and autocorrect must also be caught. The richness of modern user interfaces can make this problematic, especially within a browser-based environment.

      Any failure during edit passing results in a fork. Since each edit changes the location of subsequent edits, one lost edit may cause subsequent edits to be applied incorrectly, thus increasing the gap between the two versions. This is further complicated by the best-effort nature of most networking systems. If a packet gets lost or significantly delayed, the system must be able to recover gracefully. Google Wave is an example of a multi-user application which uses event passing as its synchronization strategy.

      Event passing is not naturally convergent.

      Three-way merges are found in Subversion, the Mjølner Project and many other products. An overview of the process is:

      • The client sends the contents of the document to the server.
      • The server performs a three-way merge to extract the user's changes and merge them with changes from other users.
      • The server sends a new copy of the document to the client.

      If the user made any changes to the document during the time this synchronization was in flight, the client is forced to throw the newly received version away and try again later. This is a half-duplex system: as long as one is typing, no changes are arriving. Shortly after one stops typing, the input from other users is integrated and either appears, or else a dialog pops up to let one know that there was a collision.

      This system could be compared to an automobile with a windshield which becomes opaque while driving. Look at the road ahead, then drive blindly for a bit, then stop and look again. Major collisions become commonplace when everyone else on the road has the same type of "look xor drive" cars.

      Three-way merges are not a good solution for real-time collaboration across a network with latency.

    • Differential Synchronization Overview

      Differential synchronization is a symmetrical algorithm employing an unending cycle of background difference (diff) and patch operations. There is no requirement that "the chickens stop moving so we can count them" which plagues server-side three-way merges.

Unsorted

  • https://en.wikipedia.org/wiki/Google_Wave

    • Google Wave, later known as Apache Wave, was a software framework for real-time collaborative online editing. Originally developed by Google and announced on May 28, 2009, it was renamed to Apache Wave when the project was adopted by the Apache Software Foundation as an incubator project in 2010.

      Wave is a web-based computing platform and communications protocol designed to merge key features of communications media, such as email, instant messaging, wikis, and social networking. Communications using the system can be synchronous or asynchronous.

    • Development was handed over to the Apache Software Foundation which started to develop a server-based product called Wave in a Box. Apache Wave never reached a full release and was discontinued on January 15, 2018.

Unsorted

  • https://crdt.tech/implementations#general-purpose-crdt-libraries

    • General-purpose CRDT libraries

    • TODO: look through the projects mentioned here and add the bigger/more relevant ones to this gist (eg. automerge, Yjs, GUN, etc)
  • https://github.com/dmonad/crdt-benchmarks

    • CRDT benchmarks A collection of reproducible benchmarks.

    • A collection of CRDT benchmarks

  • https://yjs.dev/
  • https://www.partykit.io/
  • https://github.com/Operational-Transformation/ot.js
  • https://github.com/josephg/ShareJS

    • ShareJS

      This is a little server & client library to allow concurrent editing of any kind of content via OT. The server runs on NodeJS and the client works in NodeJS or a web browser.

      ShareJS currently supports operational transform on plain-text and arbitrary JSON data.

    • Last commit: March 25th, 2016
    • https://web.archive.org/web/20120511194130/http://sharejs.org/

      • ShareJS – Live concurrent editing in your app. ShareJS is an Operational Transform library for NodeJS & browsers. It lets you easily do live concurrent editing in your app.

  • https://www.reddit.com/r/rust/comments/zk54qm/you_might_not_need_a_crdt_conflictfree_replicated/

    • You might not need a CRDT (Conflict-free Replicated Data Type) (2022)

  • https://ace.c9.io/

    • Ace is an embeddable code editor written in JavaScript. It matches the features and performance of native editors such as Sublime, Vim and TextMate. It can be easily embedded in any web page and JavaScript application. Ace is maintained as the primary editor for Cloud9 IDE and is the successor of the Mozilla Skywriter (Bespin) project.

    • https://github.com/ajaxorg/ace

      • Ace (Ajax.org Cloud9 Editor)

  • https://theia-ide.org/

    • The Eclipse Theia Platform An Open, Flexible and Extensible Platform to efficiently develop and deliver Cloud & Desktop IDEs and tools with modern web technologies. The Theia IDE is a standard IDE built on the Theia Platform.

    • https://github.com/eclipse-theia/theia

      • Theia - Cloud & Desktop IDE Framework

      • Eclipse Theia is a cloud & desktop IDE framework implemented in TypeScript.

      • Eclipse Theia is an extensible framework to develop full-fledged multi-language Cloud & Desktop IDEs and tools with state-of-the-art web technologies.

  • https://prosemirror.net/

    • ProseMirror

    • A toolkit for building rich-text editors on the web

    • Rich content editors should, ideally, produce clean, semantically meaningful documents while still being easy for users to understand. ProseMirror tries to bridge the gap between editing explicit, unambiguous content like Markdown or XML, and classical WYSIWYG editors.

      It does this by implementing a WYSIWYG-style editing interface for documents more constrained and structured than plain HTML. You can customize the shape and structure of the documents your editor creates, and tailor them to your application's needs.

    • Collaborative editing ProseMirror has built-in, ground-up, rock solid support for collaborative editing, where multiple people work on the same document in real time.

  • https://github.com/ProseMirror/prosemirror

    • The ProseMirror WYSIWYM editor

    • ProseMirror is a well-behaved rich semantic content editor based on contentEditable, with support for collaborative editing and custom document schemas.

  • https://tiptap.dev/

    • Tiptap is a headless editor framework with an open source core. Integrate over 100+ extensions like collaboration and AI agents and create the UX you want.

    • https://tiptap.dev/docs

      • Docs

    • https://github.com/ueberdosis/tiptap

      • Tiptap Editor The Tiptap Editor is a headless, framework-agnostic rich text editor that's customizable and extendable through extensions. Its headless nature means it comes without a set user interface, offering full design freedom (for a jumpstart, see linked UI templates below). Tiptap is based on the highly reliable ProseMirror library.

        Tiptap Editor is complemented by the collaboration open-source backend Hocuspocus. Both the Editor and Hocuspocus form the foundation of the Tiptap Suite.

    • https://github.com/ueberdosis/hocuspocus

      • Hocuspocus A plug & play collaboration backend based on Y.js

      • The CRDT Yjs WebSocket backend for conflict-free real-time collaboration in your app.

  • https://etherpad.org/

    • Etherpad is a highly customizable open source online editor providing collaborative editing in really real-time.

    • https://docs.etherpad.org/

      • Etherpad Documentation

    • https://github.com/ether/etherpad-lite

      • Etherpad: A modern really-real-time collaborative document editor.

      • Etherpad is a real-time collaborative editor scalable to thousands of simultaneous real time users. It provides full data export capabilities, and runs on your server, under your control.

  • https://github.com/interviewstreet/firepad-x

    • Firepad

    • Collaborative Text Editor Powered by Firebase

    • History Firepad was originally developed by Firebase Team at Google™ to showcase a Serverless and easily configurable Collaborative experience in the year of 2013.

      At first it started out with only CodeMirror editor with Rich Text support using OT to maintain consistency and concurrency. Over the years, open source contributors across the globe have added support for Ace and more recently Monaco editor, and improved overall product.

    • https://github.com/FirebaseExtended/firepad

      • Firepad Actions Status Coverage Status Version Firepad is an open-source, collaborative code and text editor. It is designed to be embedded inside larger web applications.

      • This repository has been archived by the owner on Oct 5, 2024. It is now read-only.

      • https://firepad.io/
      • https://firebase.blog/posts/2013/04/announcing-firepad-our-open-source

        • Announcing Firepad - Our Open Source Collaborative Text Editor

        • Today we’re really excited to announce Firepad, a Firebase-powered open source collaborative text editor.

          Firepad provides true collaborative editing, complete with intelligent OT — based merging and conflict resolution. It’s full-featured and has support for both rich text and code editing. Some of its features include cursor position synchronization, undo / redo, text highlighting, user attribution, presence detection, and version checkpointing.

  • https://github.com/convergencelabs/monaco-collab-ext

    • Monaco Collaborative Extensions

    • Enhances the Monaco Editor by adding the ability to render cues about what remote users are doing in the system.

    • Adds collaborative editing capabilities to the Monaco Editor

    • Last commit: September 20, 2022

      • Convergence Labs dissolved in February 2023. Please read our blog post for more information.

        • https://convergencelabs.com/blog/2023/03/convergence-labs-dissolved/

          • Convergence Labs was founded in 2017 as the business entity supporting Convergence, an engine for building real-time collaboration features and functionality.

          • Convergence has been free and open source for many years now, and its various software components will retain their current licenses (see our GitHub repo). There will no longer be an official business entity supporting the software, but we encourage anyone motivated from the existing community to jump in.

    • https://github.com/convergencelabs/ace-collab-ext

      • Ace Collaborative Extensions

      • Enhances the Ace Editor by adding the ability to render cues about what remote users are doing in the system.

      • Enhances the Ace Editor with real time collaboration user experience.

  • https://github.com/BaffinLee/collab-editor

    • Collab Editor

    • Collaborative coding editor base on Monaco Editor and OT algorithm

    • This codebase is just for fun and learning OT algorithm. BE CAREFUL WHEN USING IN PRODUCTION ENVIRONMENT.

    • https://collab-editor.pages.dev/
  • https://dev.to/shubham567/collaborative-coding-in-monaco-editor-4foa

    • Collaborative Coding in Monaco Editor (2021)

    • We will be using Monaco-Editor as our code editor. If you don't already know, Monaco-Editor is the same Editor which powers VSCode. Developed by Microsoft, is currently one of the most powerful opensource editor in market.

      We will also be using Firebase's Realtime Database as backend.

      We will be using an amazing library @hackerrank/firepad, This library will automatically take care of managing editor-state in Firebase automatically for us. Not only that but it also automatically highlight the cursor of each user and where exactly other users are typing.

  • https://akormous.medium.com/building-a-shared-code-editor-using-node-js-websocket-and-crdt-e84e870136a1

    • Building a Shared Code-Editor using Node.js, WebSocket and CRDT (2023)

    • The difficult part is conflict-resolution. You may be aware how difficult it is to resolve merge conflicts in a git repository. Imagine automating this process 😬.

      Fortunately, there are many big brain people working on distributed conflict-resolution algorithms.

      Mainly, there are 2 techniques to do this:

      • Operational Transformation (OT)
      • Conflict-Free Replicated Data Types (CRDTs)

      I won’t dive deep into the algorithmic details of each technique, but I’ll quote few lines from this blog:

      The difference is that with OT (Operational Transformation) any time you edit the document your edits have to be sent via a single server. And Google provides that server in the case of Google Docs. So all your communication, all your collaboration has to go via this one server.

      And CRDTs are different because they are decentralized. They don’t require a single server to work. But instead, you can sync your devices via any kind of network that happens to be available.

      I chose CRDTs for this project as there are many open-source implementations available with well-written documentation.

    • For the code room page, we’ll be using yjs, which is a CRDT implementation and has editor bindings for editors like Prose Mirror, Quill, Monaco Editor etc.

      We’ll be using Monaco Editor for this application. So, we need the Monaco Editor component for react and Monaco Editor binding from yjs. We’ll also need the WebSocket module of yjs which will propagate changes in the editor to the server.

      npm install monaco-editor yjs y-monaco y-websocket

    • The back-end consists of a simple express server and a WebSocketServer that listens to the ‘connection’ event and sets up a connection using a utility file provided by y-websocket module.

    • https://github.com/akormous/code-companion

      • Code Companion - Frontend

    • https://github.com/akormous/code-companion-server

      • Code Companion Server

  • https://blog.kevinjahns.de/are-crdts-suitable-for-shared-editing/

    • Are CRDTs suitable for shared editing? (2020)

  • https://zed.dev/blog/crdts

    • How CRDTs make multiplayer text editing part of Zed's DNA (2022)

    • https://zed.dev/

      • The editor for what's next Zed is a next-generation code editor designed for high-performance collaboration with humans and AI.

    • https://github.com/zed-industries/zed

      • Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.

  • https://libp2p.io/

    • the peer-to-peer network stack libp2p is an open source networking library used by the world's most important distributed systems such as Ethereum, IPFS, Filecoin, Optimism and countless others. There are native implementations in Go, Rust, Javascript, C++, Nim, Java/Kotlin, Python, .Net, Swift and Zig. It is the simplest solution for global scale peer-to-peer networking and includes support for pub-sub message passing, distributed hash tables, NAT hole punching and browser-to-browser direct communication.

  • https://tinybase.org/

See Also

My Other Related Deepdive Gist's and Projects

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment