项目地址：https://github.com/Shannon-x/chitchatter.git
一个我的实例网站：https://chat.cn9.eu/
nodeseek频道体验畅聊：https://chat.cn9.eu/public/nodeseek
几个月前发现老外有一个项目，基于浏览器的端到端加密，但是非常不稳定，而且依赖第三方的 TURN服务器，部署起来，几乎不可用。但是我非常喜欢他的理念，感觉他很可能成长为一个大项目，于是我趁着claude code特别优惠，把他优化了一下，我们的cloudflare为我们提供了一整套的Realtime实时聊天的应用环境，为什么不把他应用到这上面呢。
试想一下这样的场景：你想给微信上的一些朋友、群组分享一些翻墙的信息、分享攒劲的链接、“攒劲”的图片，但是一旦发送过去，就被微信识别到了。你想在微信发展一些可能合法可能不合法的客户，你一旦发送了消息，就在微信留下了证据，你说，我们在电报聊吧！但是什么？对面连电报是什么都不知道，甚至如何翻墙用电报都不懂，即使对面用电报，你发送了电报id,也在向微信广播说，这个id就是我！让大数据给你匹配了电报身份。
审查无处不在，大数据分析时时刻刻在为你画像，匹配你的外网账号。
“畅聊”就是为了解决这个难题而生的。他基于浏览器和cloudflare,实现端到端加密，浏览器缓存消息，一旦关闭网页，你们的聊天内容立即焚毁。
端到端传输，cloudflare只作为中继服务器，没有任何人可以截取你们的消息，即使有什么高超手段截取了，也是密文无法破译。
支持加密房间，创建私密会话，当有不法第三者扫描路径的时候企图加入房间的时候，只有双方才知道的密码提供了安全保障。在房间内，有几个人在线，一目了然。支持传输文件、图片，支持开视频，文件和图片会经过加密传输。公开频道的聊天内容仍然私密，后加入的人无法看到先前的消息！
功能特性
- 端到端加密 — 文字消息通过 WebRTC P2P 直连，端到端加密
- 去中心化 — 无中心服务器存储消息
- 即时消失 — 所有人离开房间后，对话历史自动消失
- 多人聊天 — 支持多人同时在线
- 音视频通话 — 通过 Cloudflare SFU 高效转发
- 屏幕共享 — 与房间内的人共享屏幕
- 文件传输 — 加密文件共享
- 私密房间 — 密码保护
- 身份验证 — 公钥加密验证
- Markdown — 消息支持 Markdown 和代码高亮
- PWA — 可安装为桌面/手机应用
- 多语言 — 中文/英文
- 暗色主题 — 亮色/暗色切换
技术原理详解
整体架构
本项目完全运行在 Cloudflare 生态中，使用了 5 项 Cloudflare 服务：
用户 A 的浏览器 用户 B 的浏览器
│ │
│ ① 加载前端页面 │
▼ ▼
┌─────────────────────────────────────────────────────────────┐
│ Cloudflare Pages（前端托管，全球 CDN） │
│ 托管 HTML/JS/CSS 静态文件，用户从最近的节点加载 │
└─────────────────────────────────────────────────────────────┘
│ │
│ ② 建立 WebSocket 连接到信令服务器 │
▼ ▼
┌─────────────────────────────────────────────────────────────┐
│ Cloudflare Worker Durable Object（信令服务器） │
│ │
│ 每个聊天房间 = 一个 Durable Object 实例 │
│ 职责： │
│ - 维护房间内所有在线用户的 WebSocket 连接 │
│ - 当新用户加入时，通知房间内其他人 │
│ - 转发 SDP offer/answer（WebRTC 连接参数） │
│ - 转发 ICE candidate（网络地址候选） │
│ - 用户离开时通知其他人 │
│ │
│ 注意：信令服务器只传递连接参数，不传递实际消息内容 │
└─────────────────────────────────────────────────────────────┘
│ │
│ ③ 交换连接参数后，建立直连 │
▼ ▼
┌─────────────────────────────────────────────────────────────┐
│ WebRTC P2P 直连（文字聊天） │
│ │
│ 用户 A ◄══════════ 数据通道（加密）══════════► 用户 B │
│ │
│ - 消息直接在浏览器之间传输，不经过任何服务器 │
│ - DTLS 加密，即使信令服务器被攻破也无法解密消息 │
│ - 支持发送文本、表情、Markdown │
└─────────────────────────────────────────────────────────────┘
│ │
│ ④ 音视频通过 SFU 转发（多人高效） │
▼ ▼
┌─────────────────────────────────────────────────────────────┐
│ Cloudflare Realtime SFU（选择性转发单元） │
│ │
│ 用户 A ──上传 1 路视频──► SFU ──转发──► 用户 B │
│ │──转发──► 用户 C │
│ │──转发──► 用户 D │
│ │
│ 为什么不用 P2P 传视频？ │
│ - P2P: 5人视频，每人需上传 4 路 = 20路总流量 │
│ - SFU: 5人视频，每人只上传 1 路 = 5路总流量 SFU转发 │
│ - SFU 运行在 Cloudflare 全球数百个节点，自动就近接入 │
└─────────────────────────────────────────────────────────────┘
│ │
│ ⑤ 当直连失败时（严格防火墙），走 TURN 中继 │
▼ ▼
┌─────────────────────────────────────────────────────────────┐
│ Cloudflare Realtime TURN（中继服务） │
│ │
│ 正常情况：A ←──直连──→ B （约 85% 的网络环境） │
│ 防火墙后：A ──→ TURN ──→ B （约 15% 需要中继） │
│ │
│ - Worker 调用 Cloudflare API 生成短期凭证（24h 过期） │
│ - 客户端用凭证连接 turn.cloudflare.com │
│ - 流量通过最近的 Cloudflare 节点中继 │
│ - 即使中继，连接仍然是加密的 │
│ - 免费额度：1000 GB/月 │
└─────────────────────────────────────────────────────────────┘
连接建立流程（时序）
用户A 信令服务器(DO) 用户B
│ │ │
│── WebSocket 连接 ──────►│ │
│◄── 分配 peerId ────────│ │
│ │ │
│ │◄──── WebSocket 连接 ────│
│ │──── 分配 peerId ───────►│
│ │ │
│◄── "新用户B加入" ────────│ │
│ │ │
│ [创建 RTCPeerConnection] │
│ [创建数据通道] │
│ [生成 SDP offer] │
│ │ │
│── offer (经信令转发) ──►│── offer 转发 ──────────►│
│ │ │
│ │ [创建 RTCPeerConnection]│
│ │ [生成 SDP answer] │
│ │ │
│◄── answer 转发 ────────│◄── answer (经信令转发) ──│
│ │ │
│◄────── ICE candidates 交换（双向）─────────────────►│
│ │ │
│◄══════════ P2P 数据通道建立 ═══════════════════════►│
│ （消息直接传输，不再经过信令服务器） │
bd
1年前ns有人做过类似项目，不过没你的功能全