Files on your hard drive are the ultimate local-first storage. But to allow real-time collaboration from within text editors, developers currently have to reinvent the wheel each time: Figure out how to hook into buffer changes correctly, implement displaying remote cursors, finding a way to get the required events in and out of the editor.

In addition, for each combination of editor and collaborative use-case, there needs to be a separate plugin: For example, there is a Vim plugin to connect to an Etherpad, or you need individual editor plugins when wanting to live-code music or visuals together.

Similar problems have already been solved by different editor-facing protocols: To integrate "language intelligence" tools (that provide autocompletion or refactorings), you can use the Language Server Protocol (LSP). Likewise, debugging support can be added via the Debug Adapter Protocol (DAP), and support for LLM tooling is now provided via the Model Context Protocol (MCP).

We think that there's a gap for a "Collaborative Editing Protocol" (CEP, working title) that allows text editors to talk to "collaboration servers", and thus provides them with collaboration functionality. Per editor, this protocol would only need to be implemented once, making the resulting software components interoperable. You'd have plugins for Neovim and for Emacs that speak CEP, and you'd have an Etherpad bridge that also speaks it, and you could use all of them together!

In this talk, we want to outline the requirements for a protocol like that. We'll discuss different approaches, and demonstrate the proof-of-concept protocol we built for our local-first peer-to-peer pair programming software "Teamtype". We're looking to form a group to iterate on a "collaboration protocol" together, and eventually standardize it!