# Gatherings towards a "Collaborative Editing Protocol" # Meeting #3 ## Time and date 📅 2026-04-23, 19:00-20:00 UTC [(see in your local timezone)](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20260423T19&p1=1440&ah=1) 🔗 Online, at https://meet.jit.si/collaborative-editing-protocol ## Agenda - **Terminology:** How do we talk about the protocol so that we understand each other? - What should we call this protocol? It's easier to talk about if the thing has a name - Client / Editor: The Plugin that talks the protocol with some other component and displays the content of the collaborative document - Backend: The software that sync between multiple clients / editors - Should we start a GitHub org? - We could keep our meeting notes and write a spec together there - Where are we now? - Sync realtime text between multiple parties - Cursor position + selections - unicode-codepoint offset - ID the user: name, color, image(?) - permissions: - none - read - read+write - auth should be interchangable to allow flexibility in the future - maybe define some .well-known config for the protocol - How do editors connect to backends? - Do we want to have some cep:// scheme (or similar)? - Folder structure / synced file index - What constraints could we define for a first minimal prototype of a protocol? - This could be a starting point for upcoming implementation drafts - Should we gather more people/projects? ## Notes - Naming - Collaborative editing is about syncing, so maybe as a meta idea collaborative collaborative editing protocol - CEP (Collaborative Editing Protocol) as a temporary name - we can still think about a better name in the meantime - Terminology - some refinement ideas: - less client-server architecture - editor <-> local process (optional with peer-to-peer between processes) - editor <-> server (with peer-to-peer between servers) - refer to some things as peers - initial idea by Molly and Erik: client-server architecture is simpler - server-to-server is still possible - for example TeamType could be modeled as client <-> daemon (backend) <-> other daemon (backend) <-> other client - what's a backend? - different models - what about a connection client <-> daemon <-> server (cloud)? - the different possibilities could be next steps after an initial prototype - we're all on the same page with this - Organization - Braid org is a working group, not really an implementation - could be a part of it - Molly's idea: keep it separate to reduce complexity and not include a complete ecosystem - modular specs would be nice - one wants for example only text synchronization without all multi-file index sync - purpose of Braid to build app-specific protocols - Michael would like to invite the CEP into the group - interopability is core of the protocol anyway - Braid wiki-like structure looks interesting, but separate repo for now, maybe switch later again - Where are we now? - see agenda - additions: - merge algorithms (for example singleton vs CRDT) - implementation status - Michael integrated Braid-HTTP into HedgeDoc (DiamondTypes and Yjs communicating together) - Braid-HTTP extensions integrated as well - practise to see how close are different software projects in reality - Braid extends "normal URLs" into collaborative synced ones - Molly reports that plans for HedgeDoc include keeping the non-spec-compliant endpoint for now and add a CEP endpoint as a second one later when the spec is drafted - Prototype implementation - Greg built a VS Code and vim plugin using Claude to speak Braid - writing plugins is really easy and Braid is even more general than CEP - multiple implementations and design decisions bring more variation - what is the underlying system for the initial synchronization? - HedgeDoc uses just a WebSocket - Braid-HTTP makes a long-polling GET but uses a PUT to send data - advantage over WebSocket: You don't have to ensure that the receiver has the connection open - browser implementation with fetch is easy - HTTP2 multiplexing makes it just one socket under the hood - there's also Braid-WebSocket and other transports - maybe make it transport-agnostic? - make the decision after learning from building different implementations - Python might not be the best case if we start a prototype - How much flexibility - Reach out? - <https://teamtype.github.io/teamtype/related-projects.html> - text sync could be too different, so maybe more people makes this more hard - other "features" could be discussed with other people later - collaborative text editing comes down to cursors and text, Yjs "binary blob" is the elephant in the room - more people add more complexity in design decisions - adding more people is important, but maybe a bit later - Crucial first: How to synchronize text? - Up next - Next meeting: Thursday, 2026-05-28 19:00 - 20:30 UTC # Meeting #2 ## Time and date 📅 2026-03-26, 19:00-21:00 UTC [(see in your local timezone)](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20260326T20&p1=3903&ah=1) 🔗 Online, at https://meet.jit.si/collaborative-editing-protocol ## Agenda Meta - We want to shift focus back to working on Teamtype itself => We decided to pause hosting these meetings for now. Any one wants to 'take over' the hosting, or should we stay in touch asynchronously? - Still interested to hear your thoughts on the following topics! Technical - Collecting more requirements - Does the protocol need "undo" capabilities? - How to give stability guarantees before "final" spec is done? - LSP-style capabilities? - Version numbers? - Feature autodetection - "Just use the latest version of everything" - What about e.g. Debian users? - Syncing single documents vs syncing whole directories - Hedgedoc use case: Sync one document - Pair programming use case: Sync entire directory - Tracking cursor movements across different documents - Initiating share via editor/IDE? - Compatibility of Braid's Simpleton https://braid.org/protocol/simpleton and the Teamtype Protocol https://teamtype.github.io/teamtype/editor-plugin-dev-guide.html - differences - implications of decisions - Plugin setup - What kind of configurability would the editor plugins need? - How do decide when the editors edit which resource? - Reference: Teamtype's Neovim plugin: https://github.com/teamtype/teamtype-nvim/blob/main/doc/teamtype.txt Strategy - "Directly use LSP" worth investigating/prototyping? - "Jump to cursor" features would still need plugins - LSP alway communicates *all* buffer changes to the server, even "remote" ones - Kind of a hack... - Prototype by @3timeslazy at https://github.com/teamtype/teamtype/discussions/440 - Good for adoption if the protocol "fits in" with existing protocols like LSP, DAP, MCP? - Advantages of a standard vs. premature standardization Next steps - Collecting resources: Where did you document your protocols? ## Notes - Musaab introduction - With Braid, fixed an OT bug in Hedgedoc - (see Meta in Agenda section, Teamtype team wants to de-prioritize hosting these meetings) - but interested in staying in touch + collaborating! - What requirements are needed? - keeping text in sync - positions of cursors - Is Undoing necessary? - You probably want to keep - Hedgedoc: Undo per user, only sensible solution - especially when editing in different areas - Some undo articles: - https://loro.dev/docs/advanced/undo - https://github.com/loro-dev/loro/pull/361 - https://liveblocks.io/blog/how-to-build-undo-redo-in-a-multiplayer-environment - Y.js undo manager - Greg: - When client has CRDT, it could implement the undo - In the simpleton model, it doesn't - Editor knows which edits come from whom, then apply reverse operation - In Teamtype: We don't want the full CRDT in the editor - Protocol could send an "undo" message to the collaboration server - Client could have its own undo stack, and update it like the cursors - One would need to circumvent editor's undo capabilities - loro uses undo stack per client - Batching edits, so that you don't need to undo characters individually? Group them together to words, for example? - Different editors have different concepts of what a unit of work to be undone is. - Leave this up to the editor, or integrate it into the protocol? - Could be a "recommendation" on how to implement the undo - Have it as an extension? - Common core set, capability exchange? - Extensibility = more complexity - Tradeoff: Fewer Features, but standardized vs more features, but not really standardized (as quickly) - Path of Hedgedoc: Switched to full CRDT, can now use undo within that - Seems as if undoing can be done client-side either way: CRDT has full info, simpleton can implement undo stack - Syncing single files vs whole directories - Braid: Synchronizes state - Extension: State of a directory, "Index" - JSON array, links to other resources - Syncing single files doesn't seem enough - Either sync everything in one datastructure - Sync an index, have parallel sync of documents - Features in the index: - Create, delete, rename - "Where is everybody currently?" - Identifiers for each document (as in e.g. the Reflection editor) - Moving/renaming is not a common operation when text editing - File systems have identifier concept - How to track symlinks? Identifiers would make that easier - Moving is an optional feature in Braid's index - Base data schema + extended patch type - Tree structure vs flat index? - Should scale to millions of files? - Syncthings top 1%tile users have over 1 million files: https://github.com/syncthing/syncthing/pull/10516#issuecomment-3707115707 - Braid's index can nest, or be flat - Index at the root level that points to everything in depth - Or point to subdirectories - Having the ability to use parts of the tree might be nice - permissions - subsets - Folders as different entry points into project could allow to share different parts of a project - Consensus: Directory tree structure? - You encounter file structure quickly - Flat structure might be enough in some cases - Written option might help to see if we have consensus - Step back: Should it scale to millions of files? - Musaab contributed to Syncthing - Supporting huge monorepos and the Linux kernel could be great - Permissions - Authentication + authorization of who can do what - Three options: None, only read, read+write - Permission to open real-time channel? - Switching between read + read/write maybe enough? - Related work - https://www.inkandswitch.com/keyhive/notebook/ - Maybe not exclude; Teamtype could use this! - Braid, core thing: Server tell client whether its allowed to edit - not being able to read is obvious to the client - Auth with header or cookie - From server standpoint: Users with write permissions - Client needs to be made aware - Braid: Flag per file: "is this editable to you" - Seems to fit the file index approach well - Braid: Each file has metadata (headers), which can be permissions - Teamtype could look into read-only files - in educational/presentation contexts, for example - Versioning/stability guarantees - Hedgedoc: No version differences :) - Standard should probably be implemented as a whole - work-in-progress implementations don't really matter - in case of HTTP1, timeline is rather "many years" - Updating a spec -> lots of work on implementors - Options: - capabilities, more complex? - feature detection == capabilities - Version numbers could be well-used in a group, we could use that internally - desining feature detection is more work - cautionary tale: XMPP; lots of extensions, huge implementation mess? - "caution for extensive extensibility" :P - another one: Matrix - Question: how much will the standard "change" - Risk: being too rigid/inflexible - Versioning: More flexible to iterate - "final proposed version" should be CEP 1.0 - IETF process: RFC gets number - minor errors are correctable as errata - new standard would be replacement - Two phase-approach? - Go to 1.0 when we know it will last for a long time - For Teamtype, tempted to switch how positions are defined within a file? Still care about keeping current users happy - Configurability within the protocol? - Possible via cookies? - Configuring the plugin - Related to the web index? - Or like in a file explorer: Which application will open which file? - File explorer also (similar to LSP, below) relies on file endings - or magic bytes etc - Special case for Teamtype? - But every editor plugins should be "prepared" for this use case - Diagram around CEP - LSP has a similiar problem - Which server should I use for this file - Made easier by the extension of the file - URI designed for that - Do we map external files to the filesystem? - For Teamtype, we do/need that - Is the "Teamtype plugin" on the left of the CEP diagram? - Can you sync between the sync engines or not? - Goal for the plugins: Allow it to connect to Teamtype; or Hedgedoc; or other collaborative applications - Simpler than connecting the backend - Example: making the TeamType wormhole key as a URI scheme: `wormkey:` - Example: `wormkey:6-eskimo-clockwork` - Example: `wormkey:6-eskimo-clockwork/some-file` - Equivalent to running `ethersync join 6-eskim o-clockwork` and then reading `./some-file` - Braid equivalent: `https://foo.com/some-file` - URI scheme per backend? - braid:... - hedgedoc:... - Why are the schemes necessary? - Should the "sync backends" (Teamtype/Braid/Hedgedoc) be exchangeable - Are we constrained to a "transport"? - Consensus? "Only" connecting editors to collaboration servers - Braid wants the same protocol between backends, as well as servers - Backends vary: Teamtype directory structure vs Hedgedoc document - Michael: We don't need to force it, just want to be wary of forcing backends to be different. - Collecting resources (also see below end of Meeting 1) - [ ] Have written specifications - Braid - Teamtype - HedgeDoc - Future of these meetings - If Teamtype feels the need for another gathering, we would take it up/get together again - Molly: Monthly meetings would be helpful, but we talked about many aspects, time to start hacking - Set up a Github organization? Discuss organization next time? - Make meetings shorter? Coordination problem - Some kind of meeting could help to keep this project alive? - Next time, showcase projects? - Chatroom :scream: - https://matrix.to/#/#collaborative-editing-protocol:kif.rocks - Molly can host <3 - 2026-04-23 19:00 UTC, same call room, 1h # Meeting #1 **The purpose of this meeting is to gauge interest in forming a group that works towards refining & standardizing a protocol giving real-time collaboration capabilities to existing text editors.** We believe in interoperable, free protocols, open source, and working in the open. If this speaks to you, join us! :) ## Time and date 📅 2026-02-26, 19:00-21:00 UTC [(see in your local timezone)](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20260226T20&p1=3903&ah=1) 🔗 Online, at https://meet.jit.si/collaborative-editing-protocol ## Background The idea is inspired by how the *Language Server Protocol* allows interoperability between text editors and tools providing "language intelligence" like code completions or type information. We envision a similar protocol (working title: "Collaborative Editing Protocol") for real-time collaboration that text editors (or their plugins) can implement. This would enable building programs speaking this protocol, that could enable things like "editing a Hedgedoc with Neovim", or peer-to-peer pair-programming between VS Code and Emacs.  - Moritz and blinry gave a talk at FOSDEM opening the discussion for this meeting: [Teamtype: multiplayer mode for your text editor – Towards a Collaborative Editing Protocol](https://fosdem.org/2026/schedule/event/CQHN8T-teamtype-towards-a-collaborative-editing-protocol/) (15 min) - Read Teamtype's current [Editor plugin development guide](https://teamtype.github.io/teamtype/editor-plugin-dev-guide.html#the-daemon-editor-protocol). - Teamtype also maintains a [list of related projects](https://teamtype.github.io/teamtype/related-projects.html). ## Agenda - Quick context: Vision for the protocol - Round of introductions: - Why are you here? - What interests you in a protocol giving real-time collaboration capabilities to text editors? - Which experience do you have with standardizing protocols? - Demos of prior work, if there's interest - Teamtype - Hedgedoc bridge - Braid editor plugins - *Feel free to add your tool, and give a demo!* - Scope - What are wishes/ideas for what the protocol should be able to do? - Can we identify any non-goals? - What would the protocol need so that it's useful for your project? - Technical details - Options for base protocol - JSON-RPC/msgpck-RPC to allow binary and smaller messages - LSP (extension?) - Braid-HTTP - *more*? - Base unit for position in text - Unicode codepoint offset - Line/column - Approaches for versioning the protocol itself - Strategy - Advantages of a standard vs. premature standardization - Shared ownership vs. project stewardship - Possible routes towards a standard - Technical definition - Reference implementation - Best practices? - Collecting resources: Where did you document your protocols? - What could be our next steps? - *Feel free to expand!* ## Attendees If you're interested in joining, please add your name and background below: | Name | Background | --------------- | ---------- | Moritz | Co-lead of the [Teamtype project](https://github.com/teamtype/teamtype) | blinry | Co-lead of the [Teamtype project](https://github.com/teamtype/teamtype) | Mike Toomim | Contributor to [Braid.org](https://braid.org) | Musaab Khan | Contributor to [Braid.org](https://braid.org) | Caleb Maclennan | FOSS developer | Molly | HedgeDoc Developer | Erik | HedgeDoc developer | Jonah | Commiter for [Eclipse Open Collaboration Tools](https://github.com/eclipse-oct/open-collaboration-tools) | Max | FOSS dev [Nextcloud Collectives app](https://apps.nextcloud.com/apps/collectives) | Marc | [Teamtype Jetbrains guy](https://github.com/teamtype/teamtype-jetbrains/) | | You? | ## Discussion Notes - no notes in Teamtype yet :D ### Intros - Moritz - timekeeping today :) - Jonah - Typefox - Open Collaboration Tools - Theia/VS Code, now branching out - Protocol embedded in the plugins - Marc - Jetbrains plugin for Teamtype - Interested in mob programming, mob.sh - Wanted IntelliJ <-> Neovim collaboration - Greg - Working on Braid - Braid: More than text editor sync! - Molly - Working on Hedgedoc, 1.x + 2.0 - inherited the project 5 years ago - Michael - Co-founder of Braid - Interoperable state sync - Helps interoperable state sync - Coming up with standards - Musaab Khan - github.com/bxff - Caleb - Also for non-programmers - Consulting for publishers - Working with people not familiar with version control - Problem: Typesetters don't necessarily understand the technical pipeline - Long experience with open source, pair-programming w/ Vim + Tmux - Rob - Microsoft; here in private capacity - Interest in collaborative editing - Contexts like document production - Michl - Interested in the technology - Mob programming! - Interested in CRDTs - Erik - Hedgedoc - Rewrite still ongoing -> CRDTs, nicer looks - Exploring in possible integration with Teamtype ### Demos - Teamtype - Teamtype-Hedgedoc bridge - Braid - Parts that synchronize: - Emacs - Chrome extension - Web component - File system - Goal: State Synchronization (generalization of text sync) - Braid-HTTP as an extension to HTTP - HTTP -> sync - 4 extensions - Broad interop, map them together to a common model - Extend HTTP to P2P - Iroh, QUIC - Edit history visible in dev tools - Emacs plugin has ~600 lines to speak HTTP - Another ~600 lines to implement the sync itself - Simpleton algorithm doesn't keep history, and relies on the server to do the transformation - Open Collab Tools - needs a server instance which acts as a message relay and handle authentication - Open Collaboration extension in VS Code - Monaco integration in the browser - Shows open files - Protocol via websocket, msgpack - broadcast, to everyone - notification, to specific user - requests, mostly to the host but can go to everyone - like 'stat' - Y.js as a CRDT library - One person shares, others have virtual view on the file system - IntelliJ integration on the way with a nodeJs based service process doing the CRDT and lifecycle management - service process communication is JSON-RPC via stdio - Hedgedoc - Version 2 - list of latest/recently visited notes - Y.js - REST API with access token - permission system - marking as public - upload management - notes with multiple URLs - technical - websockets - JSON (easier to debug) on top of Y.js - syncing several states: users, cursors - authorship tracking - maybe switch to CBOR instead to save bandwidth - Version 1 - Socket.IO, OT-based ### Scope - Wishes/ideas - Requirement ideas - Common - Sync text in "realtime" - Multiple participants - Sync cursor positions + selections - ID for the user: name, color, image - compact/binary protocol? - Not needed by everyone - Hedgedoc: Extensibility for new message types - Permission changes - Some requests might be very tool-specific? - OCT also would need custom messages - Diagram types, not just text - Teamtype: Directory sharing, not just single files - Michael: HTTP also extensible - Syncing single files vs syncing full directories - Braid: text content type vs index content types - P2P URLs? - Opening specific files - Content layer vs interaction layer - Syncing binary files - Scope - Q: Mainly focus on plaintext? Or make it general? - Custom sync engines for different content types - Michael: First step towards general picture - Teamtype uses two protocols: Daemon-daemon and Editor-daemon - Breaking these up seems useful? - Daemon is rebasing edits for the editors - Braid's collapsing time machines - Editor just needs to speak the simpleton merge-type - Feature ideas - authorship tracking - Hedgedoc stores user of that edit - permissions - chats about the document - annotation - Non-features - Rich-text? - Audio/video channel - Many teams already have that? ### Technical - Base protocol - Hedgedoc: Emotionless, whatever works - Goals: Good developer experience - We want it to be used; for devs should be easy to "just use it" - Molly: SDK is nicer than "just a spec" - Libraries make it easy, simple protocol makes it easy - Extensibility - JSON-RPC makes transferring binary content harder - Reduce number of layers - LSP wrapper as an "easy win" - Base unit for position - Greg: Care about Unicode code points, \r\n - "most simple way to represent things" - Line/column not useful for soft line wrapping - Tools that are not code editors - Line/column was copied from LSP - - Versioning - IETF people don't tend to design in versioning - consensus -> protocol "already works" for everyone - resumable upload spec added a version number, but got removed again - version numbers for internal development only - LSP-like capabilities checking - clients and servers signal what they can do to each other - Braid uses different merge-types, hopefully implementors implement them similarly - Different merge types can be used for different CRDTs behind them ### Strategy - Braid is aiming at an IETF standard - Motivation: We don't want 5 different versions [insert xkcd here] (https://imgs.xkcd.com/comics/standards.png) - IETF represents the whole Internet - first iteration was a websocket one - broke spec up - Dreaming of the future of "one distributed web" - Molly, options: - using Braid as a very general solution - "Meta protocol" - Collection of protocols that form the "collaborative editing" experience - Express as constrained usage of Braid-HTTP - Alternatives to IETF process - Example: JSON-Schema, was IETF draft - If protocol is "good enough", it will spread - LSP was also specified by Microsoft - Might be cool to connect to each others ### Resources - https://braid.org meets every 2 weeks - Braid Discord: https://discord.gg/nvPQN7FgDX - Braid Mailing List: https://groups.google.com/forum/#!forum/braid-http - Michael Toomim (signal, imessage, whatsapp): +1-510-282-4312 and toomim@gmail.com - Index/Directory sync spec: https://braid.org/protocol/web-index - Multiplayer cursors sync spec: https://braid.org/protocol/cursors - Braided Hedgedoc impl: https://github.com/braid-org/braided-hedgedoc - HedgeDoc - Matrix chat for dev related topics: https://chat.hedgedoc.org/dev - Discourse forum: https://community.hedgedoc.org - almost weekly development meetings via Mumble, just send a message in the dev chat if interested to join - <cep@hedgedoc.org> - Protocol: Y.js + custom commands - Teamtype - <teamtype@zormit.de> - https://teamtype.zulipchat.com is our development chat, has a #editor-protocol channel - Mastodon account: https://fosstodon.org/@teamtype - Source code: https://github.com/teamtype/teamtype - Editor protocol documentation: https://teamtype.github.io/teamtype/editor-plugin-dev-guide.html#the-daemon-editor-protocol - "Decision documents" https://github.com/teamtype/teamtype/tree/main/docs/decisions - https://www.open-collab.tools/ - OCX Presentation on the tool https://www.youtube.com/watch?v=m50p6fQOH-w&list=PLy7t4z5SYNaRRGVdF83feN-_uHLwvGvgw&index=3&pp=iAQB - Jonah Iden (jonah.iden@typefox.io) - ### Next meeting/next steps - Meet again in 1 month: March 26th, 19:00-21:00 UTC [(see in your local timezone)](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20260326T20&p1=3903&ah=1)