Chitchatter
更新于 2026-09-19 20:34:00
它是什么
Chitchatter 是一个无服务端（serverless）的 P2P 通信工具：打开 https://chitchatter.im/、进一个房间、把链接发出去，剩下的全在浏览器之间直连完成。仓库自称的核心卖点是 No API server required——它把「中央依赖」压缩到了理论上的最小值：
| 依赖 | 用途 | 是否必须 |
|---|---|---|
| 静态托管（GitHub Pages / Vercel / 任意静态站） | 分发前端资源 | ✅ 必须（但只是个静态文件服务器） |
| 公共 WebTorrent tracker（Trystero 信道） | 帮房间里的 peer 互相发现 | ✅ 必须（用公共的，项目不运营） |
| TURN 中继 | 直连不通时兜底 | ⚠️ 仅在网络条件不允许直连时用到 |
| Chitchatter API 服务 | 增强连接性（动态下发 TURN 配置） | ❌ 完全可选，不装也能用 |
也就是说：没有任何 Chitchatter 官方服务器参与你的通信，用到的信令信道和 TURN 都是公开的第三方基础设施，项目与它们没有关联。甚至 https://chitchatter.im/ 本体的 IP 也可以用 dig 验证指向 GitHub Pages（185.199.x.x），代码全部开源、构建日志公开，可自行审计。
关键设计：临时性（Ephemeral）
这是它和其他聊天/会议工具最大的区别，也是选择它之前必须接受的设定：
- 消息永不落盘。客户端和服务器都不持久化消息内容，离开房间即从内存清除，无法找回。
- 新加入者会从当前在线的 peer 那里回填历史（conversation backfilling）——所以历史只存在于"当时在线的人"的内存里。所有人都走了，这段对话就永久消失了。
- 无账号、无好友列表、无好友请求。身份靠客户端公钥自动互相验证。
- 文件传输：不限大小，发送前加密、接收方解密，加密密钥就是房间名，因此房间名本身就是安全边界。
功能
- 一个房间多个 peer（上限取决于浏览器支持的 peer 连接数）
- 公共房间 / 私有房间
- 视频与音频通话、屏幕共享、私聊（DM）
- 文件传输：不限大小，端到端加密
- iframe 嵌入已有 Web 应用
- Markdown 渲染（含代码高亮）、多行消息、深色/浅色主题
- 官方 SDK：
<chat-room />Web Component，几行 HTML 就能把聊天室嵌进任何页面
上手：三条路
① 直接用（零成本）
打开 https://chitchatter.im/，默认会给你一个随机 UUID 房间名，点右上角 🔗 分享链接即可。建议通过 Yopass 之类的临时渠道发链接，别走明文 IM。
② 嵌入 SDK
<script src="https://chitchatter.im/sdk.js"></script>
<chat-room room="my-room" user-name="Pico" color-mode="dark"></chat-room>
支持的属性：room / user-name / user-id / root-url / color-mode / play-message-sound，以及标准的 height / width / style / sandbox 等 iframe 属性。
③ 自托管
npm install
npm start # 前端开发模式，用公共 WebTorrent tracker，http://localhost:3000
npm run build # 产出 dist/，丢到任意静态托管即可
可选再起一个 API 服务（Vercel dev 或仓库里的 simple-api-server.js）来下发 TURN 配置，即上文提到的 Enhanced Connectivity 功能。注意：目前开发环境只支持 *NIX（Linux/macOS），Windows 需要 WSL。
这些坑必须提前知道
- 通信完全是 mesh。每人要和房间里其他所有人各建一路连接，3-4 人体验最好，人一多浏览器连接数和上行带宽就顶不住。这不是配置问题，是架构决定的。
- 跨域名不通。
chitchatter.im和官方 Vercel 镜像属于不同域，两边的 peer 无法互相连接。自建实例同理——自建的人和公共实例的人不能互通，必须约定好同一个入口。 - 房间名 = 加密密钥 = 安全强度。别用
meeting、team这类可猜名字；用随机 UUID 房间，通过安全渠道分发链接。默认生成的随机房间名就是为了这个。 - 没有历史记录是双刃剑。合规上很省事（无数据留存、无分析埋点、无遥测），但你要是想「回看上次会议讨论了什么」，做不到。
- 项目处于维护模式。作者明确表示功能上已「feature-complete」，未来只修重要 bug，不主动加功能（付费定制/定制安装可以联系作者）。选它意味着接受一个稳定但停滞的代码库——好处是 API 不会再变，坏处是别指望新特性。
- 需要公钥基础设施吗？不需要。但这也意味着没有服务端准入控制——房间里的信任完全建立在「谁知道房间名」上。
适用场景
- 小圈子私密对话（工会/兴趣小组/临时协作），不想让任何服务商存数据
- IT 远程排障：屏幕共享 + 无留痕，客户不用装任何东西
- 跨设备搬运文本或文件（手机↔电脑，不限文件大小）
- 传递敏感信息（密码、密钥、合同），配合随机房间名与安全分发渠道
- 嵌进自有系统：用 SDK 把聊天室塞进内网页面，服务端零改造
和同类方案怎么选
| 你的核心诉求 | 选它 |
|---|---|
| 连服务器都不想自建，打开网页就用、无账号、无留存 | Chitchatter（本项目） |
| 要正经开会：白板、录制、REST API、iframe/widget、133 语言，可自托管 | MiroTalk P2P（信令只建链 + mesh，AGPL-3.0） |
| 要真正的去中心化身份与 DHT 寻址，桌面/移动原生客户端 | Jami（OpenDHT，bootstrap 节点只用于首次入网；注意其 GitHub 仓库只是 Gerrit 镜像，星级不代表真实流行度） |
| 超过 8 人、要大规模稳定 | SFU 方案（MiroTalk SFU / Jitsi Meet） |
一句话区分：Chitchatter 是「零运营」的极致，MiroTalk 是「可自持」的正经会议产品。前者省掉了运维，后者换来了会议功能和可控的部署形态。
上手评价
- 安装成本几乎为零：不自建就是打开网页，自建也就是
npm run build丢静态托管，没有数据库、没有后端要维护。 - 隐私模型干净：无账号体系、无埋点、端到端加密、消息不落盘，安全审计面很小。
- 诚实的文档：README 里专门写了 "Anti-features"（不持久化、无常驻 API 服务、无遥测），把限制摊在明面上，这点很加分。
- 代价是能力天花板：没有会议预约、没有录制、没有会议管理、没有大体量会议，本质是「加密聊天室 + 音视频通话 + 文件传输」。
- 许可证是 GPL-2.0（不是 AGPL），比 MiroTalk 的 AGPLv3 宽松，内部自用和嵌入都非常舒服。
- 生态位风险：单人主导 + 维护模式，长期看依赖作者的个人意愿；好在前端纯静态、技术栈常规（Vite + React + Trystero），真要接手或 fork 成本不高。
二开与集成建议
- 先想清楚要不要自建：只做内部使用，直接在官方实例上开随机房间即可，省掉全部运维。
- 自建时开启 hash 路由：
VITE_ROUTER_TYPE=hash，这样房间名只出现在#后面，服务器在访问日志里看不到房间名，隐私收益明显。 - 给自建实例配 TURN：用
npm run generate-rtc-config生成 base64 的RTC_CONFIG，通过环境变量注入；不配的话 Enhanced Connectivity 的 UI 会自动隐藏（作者已经处理好这个分支），但仍然只能依赖兜底 TURN，弱网下丢连接概率会高。 - 嵌入用 SDK 而不是手写 WebRTC：
<chat-room />直接复用整套信令与加密逻辑，比自己攒 PeerJS 稳得多。 - 别把密钥塞进房间名里：房间名虽然参与加密，但会出现在 URL 和浏览器历史中，敏感场景请额外用带过期时间的渠道分发链接。
- fork 前先看 roadmap：作者的 issue 看板公开，真要做产品化改造（多房间管理、持久化、企业 SSO），这些都属于它有意不做的方向，适合另起分支。
一句话总结
如果 "中央服务器" 这件事你想砍到只剩一个静态文件托管，Chitchatter 是目前最接近极限的实现：无账号、无后端、无留存，打开链接就直连，连官方 demo 都只是跑在 GitHub Pages 上；代价是 mesh 架构限制在小规模、历史记录不可追、项目已进入维护模式——把它当成「用完即焚的加密房间」，它会非常称职。