ECCP

Layered Docs

Reference material for protocol builders, operators, and client teams.

ECCP separates messaging basics, server operations, protocol concepts, and implementation guides so each layer stays understandable.

Static export ready

Static MDX guides, Shiki code fences, sidebar navigation, and bilingual routing for English and Traditional Chinese readers.

Messaging Basics

Create invitation-based rooms, understand visibility, and keep conversation boundaries legible.

Updated 2026-04-08/docs/private-rooms

Private Rooms

ECCP private rooms are optimized for clear participation boundaries. The goal is not to hide that a room exists from every system forever; the goal is to make membership, visibility, and message access explicit.

Room Visibility Modes

| Mode | Discoverable | Join path | Typical use | | --- | --- | --- | --- | | private | No | Direct invite | Team rooms, DMs, private projects | | invite_only | No | Moderated invite | Sensitive working groups | | shadow | No public metadata | Invitation payload only | High-sensitivity coordination |

Invite the Right People

Clients should display both the homeserver identity and the device verification state when inviting a new member. ECCP assumes that room safety depends on participants understanding who joined and which devices can decrypt.

  • Use invite-only membership for rooms that coordinate real-world actions
  • Require verification before granting moderator-level privileges
  • Keep history visibility narrow until trust relationships are established

Example Room Creation

TypeScript snippet

TypeScript

1
2
3
4
5
6
await client.rooms.create({
  name: "Design review",
  visibility: "private",
  joinRule: "invite",
  historyVisibility: "invited"
});

Keeping a Group Safe

The client layer should explain:

  • whether new members can read old history
  • whether bots are present
  • whether bridged users are part of the room
  • whether the room lives on one node or multiple federated nodes