Feature Request: Cross-Editor Collaboration Protocol & Extension API

[Amiya167]

Body

This document is drafted as a GitHub Discussion feature request for the Zed project.
It follows Zed's feature request guidelines.

---

What are you proposing?

A cross-editor collaboration protocol and corresponding WASM extension API surface that allows third-party editors to participate in Zed collaboration sessions as first-class peers.

Concretely, we propose three additions:

1. An open collaboration wire protocol specification — a documented subset of Zed's existing Protobuf RPC that external clients can implement to join rooms, share projects, and sync buffers.
2. A collaboration WIT interface for WASM extensions — so extensions can observe and react to collaboration events (presence, buffer operations, cursor positions).
3. Pluggable authentication providers — allowing organizations to use their own OIDC/OAuth identity provider instead of requiring Zed Cloud + GitHub OAuth.

---

Why does this matter?

The problem

Real-time pair programming today is fragmented by editor choice. If one developer uses Zed and their partner uses a different editor, they cannot collaborate in real-time — they must both switch to the same tool or fall back to screen sharing.

Zed already has one of the most sophisticated real-time collaboration systems in any editor (Protobuf RPC, CRDT-inspired conflict resolution, Lamport timestamps + vector clocks). But this system is currently closed — only Zed clients can participate.

What becomes possible

• Cross-editor pair programming: A developer in Zed and a developer in another editor (e.g., Logos, Neovim with a plugin, a web IDE) could edit the same project in real-time.
• Enterprise adoption: Organizations often standardize on one identity provider (Okta, Auth0, Keycloak, self-hosted OIDC). Pluggable auth removes the GitHub-only requirement.
• Extension ecosystem growth: Collaboration-aware extensions could build features like shared debugging sessions, collaborative code reviews, or AI-assisted pair programming that work across editors.
• Zed as a collaboration platform: Rather than just an editor, Zed becomes the infrastructure layer for real-time code collaboration — similar to how LSP made language intelligence portable.

Who benefits

• Zed users: More people they can pair program with, regardless of the partner's editor choice.
• Extension authors: New category of collaboration-aware extensions.
• Enterprise teams: Can adopt Zed collaboration without abandoning their IdP or mandating a single editor.
• The broader ecosystem: An open standard for editor collaboration, similar to what LSP did for language intelligence.

---

Are there any examples or context?

Precedent: Language Server Protocol (LSP)

Before LSP, every editor had its own language intelligence system. Microsoft published LSP as an open protocol, and now any editor can use any language server. The result was explosive growth in language tooling.

We believe real-time collaboration is at a similar inflection point. Zed's protocol is already the most capable implementation — publishing a subset as an open spec would establish Zed as the standard, much like VS Code's LSP.

Existing architecture analysis

We have studied Zed's collaboration implementation in detail:

Component	Location	Relevance
Protobuf schema	crates/proto/proto/zed.proto	430+ message types; a subset (~40 messages) covers core collab
RPC peer model	crates/rpc/src/peer.rs	Connection management, keepalive, timeouts
Auth flow	crates/rpc/src/auth.rs	RSA key exchange + GitHub OAuth — needs abstraction
Text CRDT	crates/text/	Lamport timestamps + vector clocks for conflict resolution
Collab server	crates/collab/	Room/project/buffer state management
WASM extension host	crates/extension_host/	Current WIT interfaces (v0.8.0) — no collab APIs

Cross-editor scenario

We are building Logos, an Electron + Vue 3 editor with Monaco. We want our users to pair program with Zed users. We are willing to:

• Implement Zed's collaboration protocol on our side
• Contribute patches to Zed if needed
• Co-develop the protocol specification
• Build and maintain a reference bridge implementation (Aefanyl)

---

Possible approach

Phase 1: Protocol specification (documentation only, no code changes)

Document the minimum viable subset of zed.proto that an external client must implement:

Session lifecycle (~10 messages):

Hello, Ack, Ping, Error
CreateRoom, JoinRoom, LeaveRoom, RoomUpdated
ShareProject, JoinProject, LeaveProject

Buffer synchronization (~8 messages):

OpenBufferById, OpenBufferByPath
UpdateBuffer (Edit, Undo, UpdateSelections)
SaveBuffer, ReloadBuffers
BufferSaved, BufferReloaded

Presence (~4 messages):

AddProjectCollaborator, RemoveProjectCollaborator
UpdateParticipantLocation
Follow, UpdateFollowers

File operations (~6 messages):

CreateProjectEntry, RenameProjectEntry, DeleteProjectEntry
CopyProjectEntry, SynchronizeBuffers

This is roughly 30 messages out of 430+ — a manageable surface for external implementors.

Phase 2: Pluggable authentication

Abstract the auth flow in crates/collab/src/auth.rs:

// Current: hardcoded GitHub OAuth + Zed Cloud
// Proposed: trait-based auth provider

#[async_trait]
pub trait AuthProvider: Send + Sync {
    /// Validate an authorization header and return user info.
    async fn authenticate(&self, header: &str) -> Result<AuthenticatedUser>;

    /// Return the OAuth authorization URL for login flow.
    fn authorization_url(&self) -> &str;
}

pub struct AuthenticatedUser {
    pub id: UserId,
    pub display_name: String,
    pub avatar_url: Option<String>,
    pub email: Option<String>,
    pub provider: String,  // "github", "oidc", etc.
}

// Built-in providers:
// - ZedCloudAuthProvider (current behavior, default)
// - OidcAuthProvider (new: standard OpenID Connect)

Server configuration (environment variables or config file):

[auth]
provider = "oidc"   # or "zed-cloud" (default)

[auth.oidc]
issuer = "https://id.example.com"
client_id = "zed-collab"
client_secret_env = "ZED_OIDC_SECRET"
scopes = ["openid", "profile", "email"]

Phase 3: Collaboration WIT interface for extensions

Add a new WIT interface (collaboration.wit) to crates/extension_api/wit/:

interface collaboration {
    // Session awareness
    get-session-info: func() -> option<session-info>;
    get-collaborators: func() -> list<collaborator>;

    // Event subscription (extension exports these)
    // Host calls these when collaboration events occur
    on-collaborator-joined: func(collaborator: collaborator);
    on-collaborator-left: func(collaborator: collaborator);
    on-buffer-operation: func(buffer-id: u64, operation: buffer-op);
    on-cursor-update: func(collaborator-id: string, file-path: string, position: position);

    // Types
    record session-info {
        session-id: string,
        is-host: bool,
        project-path: string,
    }

    record collaborator {
        id: string,
        display-name: string,
        avatar-url: option<string>,
        editor-name: string,      // "zed", "logos", "neovim", etc.
        replica-id: u32,
    }

    record position {
        line: u32,
        column: u32,
    }

    variant buffer-op {
        insert(insert-op),
        delete(delete-op),
    }

    record insert-op {
        position: u64,
        content: string,
    }

    record delete-op {
        position: u64,
        length: u64,
    }
}

This would enable extensions like:

• Collaborative AI assistants that see all participants' edits
• Shared debugging sessions
• Code review tools that sync annotations across editors
• Presence-aware git conflict resolution

Phase 4: Reference bridge implementation

We will build Aefanyl — an open-source collaboration bridge that:

• Speaks Zed's Protobuf RPC protocol on one side
• Exposes a WebSocket + JSON-RPC API for simpler clients on the other
• Handles protocol translation, auth bridging, and session relay
• Can run self-hosted alongside a Zed collab server

This is our responsibility to build and maintain, not Zed's. We mention it here for context on how the ecosystem would work.

---

Summary of asks

Ask	Impact on Zed codebase	Benefit
Document collab protocol subset	None (docs only)	External clients can implement
Pluggable auth provider trait	Small refactor in crates/collab/src/auth.rs	Enterprise adoption
Collaboration WIT interface	New file in crates/extension_api/wit/	New extension category
Self-hosted collab server docs	None (docs only)	On-premises deployment

We are happy to contribute PRs for any or all of these.

---

About us

We are the team behind Logos IDE, a desktop code editor built with Electron + Vue 3 + Monaco Editor. We have an existing SSH remote development system, a Rust language analysis daemon, and both VS Code extension hosting and WASM extension support.

We believe Zed's collaboration infrastructure is the best in the industry, and we'd rather build on it than reinvent it. Our goal is interoperability, not competition.

[Amiya167]

cc： @defunkt @paul @raggi @palmamartin

[Amiya167]

Development is temporarily hampered due to staff shortages and insufficient Claude Code quotas. Please be patient.

[Amiya167]

Development of Yuxu (玉虚宫) — the Zixiao Labs DevOps platform — has officially resumed. The frontend scaffolding (React + MUI + chen-the-dawnstreak router + Nasti bundler) and the Rust backend skeleton are in place. We are now building out the core UI: dashboard, repository management, issue tracking, merge requests, and CI/CD pipeline views.

This platform will serve as the foundation for integrating the cross-editor collaboration protocol proposed in this discussion. The CRDT-based real-time collaboration layer is a first-class design goal, not an afterthought.

Next milestones:

• Complete the frontend layout and core page routing
• • Implement Git repository hosting and browsing APIs in the Rust backend
• • Begin prototyping the collaboration wire protocol subset (Phase 1 from the proposal above)
    We appreciate everyone's patience during the staffing hiatus. Development is now proceeding at full speed with Claude Code assistance. Will continue posting updates here.

Repo in there

[Amiya167]

If all goes well, the backend should be available today, at which point we will receive the first pull request for this discussion.

[Amiya167]

Of course, the front-end needs to be redesigned, so the CLI interface and the panel in Zed will be released first (the front-end and the panel on the Logos side will be released after the Claude Pro subscription quota is restored).

[Amiya167]

Update: JSON-RPC to Protobuf (aefanyl) is now deprecated. Cross-editor collaboration will now uniformly use Protobuf and be managed by YuXu DevOps. We believe this is closer to the native approach and avoids the performance overhead and technical debt caused by additional middleware.

[Amiya167]

We've started a new Claude Code thread, which will be implemented here; the pull request will be ready shortly.
View On Claude Code