私人房間

ECCP 的私人房間設計重點是清楚的參與邊界。目標不是讓所有系統永遠完全不知道房間存在，而是讓成員、可見性與訊息存取條件都保持明確。

房間可見性模式

| 模式 | 可被發現 | 加入方式 | 常見用途 | | --- | --- | --- | --- | | private | 否 | 直接邀請 | 團隊房間、私訊、私人專案 | | invite_only | 否 | 經審核邀請 | 高敏感工作群組 | | shadow | 無公開中繼資料 | 只能依邀請載荷加入 | 高風險協調工作 |

只邀請對的人

客戶端在邀請新成員時，應同時顯示 homeserver 身分與裝置驗證狀態。ECCP 假設房間安全性來自參與者理解誰加入了房間，以及 哪些裝置 能解密訊息。

建議預設值

真正涉及行動協調的房間，使用 invite-only 成員規則
在授予管理權限前，先完成裝置驗證
在信任關係建立之前，將歷史可見性維持在最小範圍

房間建立範例

TypeScript snippet

TypeScript

await client.rooms.create({
  name: "設計審查",
  visibility: "private",
  joinRule: "invite",
  historyVisibility: "invited"
});

讓群組保持安全

客戶端層應清楚解釋：

新成員是否能閱讀舊歷史
房間裡是否存在機器人
是否有橋接使用者進入房間
房間是單一節點還是跨聯邦節點運作

提供給協議實作者、節點營運者與客戶端團隊的參考資料。