ECCP
Layer 1 — Protocol

Open rules for encrypted federation.

ECCP is an open communication standard, not a closed SaaS backend. The protocol layer defines X25519 handshakes, Double Ratchet messaging, signed federation envelopes, and sync semantics so homeservers and clients can interoperate without permission.

X25519Double RatchetHKDF-SHA256Signed Federation
Read the draft specExplore homeservers

Layer Mapping

Layer 1 keeps cryptography, sync, and federation portable.

Layer 2 nodes implement the spec and expose self-hostable trust boundaries.

Layer 3 clients such as PrivChat and exine focus on UX, not protocol invention.

Layer 4 extends the stack with Shadow Rooms, Bot API hosts, and bridges.

Flow Topology

Federation remains visible, auditable, and portable.

ECCP keeps the boundary lines explicit. Clients speak to their homeserver, homeservers exchange signed protocol events, and every other layer builds on those open rules instead of private backend APIs.

ECCP federated protocol topologyLayer 3Layer 2Layer 3ClientPrivChatEveryday users keep familiar UX,while ECCP handles trust and sync.ClientexineDeveloper-facing clients reusethe same transport and key semantics.Homeservernode.eccp.devLayer 2 nodes handle auth, room state,local storage, and outbound federation.Layer 1Federation CloudSigned envelopes and sync fanoutECCP signs federation events, validates device manifests,and keeps sync portable across independent implementations.Homeserverrelay.alphaIndependent operators federatewithout asking a central vendor.Homeserverselfhosted.labHomeservers can be public, private,regional, or invite-only.ClientOther ClientsThird-party apps can implement ECCPand still join the same network.ClientBridge AppsLayer 4 bridges and bots attachabove the protocol instead of replacing it.
Specification Surface

Concrete primitives, not fuzzy privacy claims.

ECCP does not market “military-grade” abstractions. It publishes the exact mechanisms implementations are expected to follow, with enough detail for interop tests and audits.

X25519 Device Handshake

Each device establishes its session identity through X25519 key agreement and signed device manifests.

Double Ratchet Sessions

Room traffic uses Double Ratchet message chains for forward secrecy and practical post-compromise recovery.

Deterministic Key Schedule

HKDF-SHA256 derives message keys, attachment keys, and cross-device recovery material from explicit state transitions.

Signed Federation Events

Homeservers exchange canonicalized event envelopes so federation remains inspectable, replay-safe, and independently testable.

Version Timeline

Versioned in public, designed for independent implementations.

v0.1

April 2026

Draft core spec for device identity, room state, transport envelopes, and baseline federation semantics.

v0.2

June 2026

Attachment envelopes, partial-state sync, and explicit homeserver capability negotiation.

v0.3

September 2026

Bridge envelopes, Bot API capability grants, and audit fixtures for third-party implementations.

v1.0

Q1 2027

Stable interoperability target for clients, nodes, and the wider Layer 4 ecosystem.

Documentation

Read the draft, run the tests, build your own implementation.

ECCP only becomes credible when protocol builders, homeserver operators, and client authors can all inspect the same source of truth.

Open docsJoin the review loop