一句话结论

「加密」有三种,只有第三种(端对端)会让 AI 读不到。 前两种我们现在就能做、AI 一点不受影响,但它们挡的是「被偷」,挡不了「我们自己能看」。 真正的端对端加密和「服务器上的 AI 能读消息」在同一条消息上不可能同时成立 —— 所有大厂都是在两者之间选边或者分房间,没有第三种魔法。

我的建议:A + B。现在先把看不见的两层补上(AI 照常);再做一个「加密房」开关,打开的那间房里 AI 默认不读,要用 AI 就自己 @ 它、只把那一句交给它 —— 第一批拿幽灵房试。

三种「加密」,各挡什么

你问的「群里点一下开启加密」:各家不一样,要看它把钥匙放在哪 —— - 如果钥匙只在手机上(服务器只转发看不懂的乱码)= 端对端。代价通常是:那间房的历史不进云、换手机看不到、搜索只能在本机、群人数有限。 - 如果钥匙在服务器上 = 只是 ① / ②,换了个好听的名字。判别办法很简单:换一台新手机登录,旧聊天还能直接看到吗? 能看到 = 服务器手里有钥匙 = 不是端对端(除非它做了钥匙备份,见下面「难点」)。

别人怎么做

• 微信:没有端对端加密。有传输加密(腾讯自己的一套协议)和服务器端的保护,聊天内容服务器读得到。所以微信能做云端搜索、内容审核、各种服务器上的功能。
• WhatsApp:一开始没有,2016 年起全部私聊和群聊默认端对端(用的是 Signal 的协议)。后来加 Meta AI 的做法是:你主动 @Meta AI 或者单独和它聊,只有你发给它的那几条会交给 AI,其余聊天 AI 看不到。
• Facebook Messenger:先做成可选(2016 年「Secret Conversations / 秘密对话」,要单独开一个对话),2023 年底才改成私聊默认端对端。—— 你说的「一开始没加密、后来才加」,这两家都是。
• Telegram:默认不是端对端(普通聊天是「云聊天」,服务器能解开,所以多设备、云端搜索都很方便);要端对端得单独开「Secret Chat / 秘密聊天」,只能一对一、不能群聊、只在那一台手机上。—— 「点一下开启加密」最典型的就是它。
• Signal:全部端对端,服务器几乎什么都不知道;代价是很多「云上」的功能都没有。
• Apple(iMessage + Apple Intelligence):iMessage 端对端;AI 功能尽量在手机上跑,手机跑不动的才送到他们自己特制的服务器(号称不留存、外部可审计)。这是「既要端对端,又要 AI」目前最完整的做法,也是成本最高的做法。

规律:要么像微信 / Telegram 普通聊天那样服务器能读(功能多、AI 方便);要么像 WhatsApp / Signal 那样服务器不能读(AI 要么在手机上跑,要么用户每次主动交给它);Messenger、Telegram 都走过「先做成可选的加密房,再决定要不要默认」这条路。

HOOP 今天:哪些功能靠服务器读明文

(2026-10-01 从代码盘点,端对端一开,这些在那间房里都要停或者重做)

AI 类 - 个人 AI 助手:每条消息交给它,它再拉最近 20 轮上下文去问模型 —— assistant/service.go:210、:755;挂在 message/service.go:473 - 房间 AI(问 / 气氛 / 帮我写):读最近 60 条 —— ai/service.go:52,71,109,166 - 文件「AI 总结」:服务器下载附件、抽文字、送模型 —— ai/summarize.go:74 - 援兵 AI 读房(MCP 的 chat_read / attachment_read):服务器把明文和附件交给外面的 AI 分身 —— mcp/tools_chat.go:45,193。每个 AI 分身等于又一台要钥匙的设备 - 暖度打分:每条私聊文字过一遍词典 —— warmth/service.go:121;资源掉落也用它 —— resource/service.go:98 - 聊天工具「扫一扫 / 问图」:图片送视觉模型 —— chattool/scan_chat.go:59

非 AI 类(同样会受影响) - 搜索:消息正文写进 Meilisearch,服务器上搜 —— message/service.go:222、platform/search/meili/meili.go:50 - 推送:锁屏通知里带消息原文(文字前 80 字)—— message/service.go:3106 起的 pushPreview,push/apns.go:82 - 链接预览:服务器去抓第一个链接的标题图 —— message/linkpreview.go - 会话列表的「最后一条」预览、回复引用、投票 / 活动 / 接龙的内容,都是服务器读写的

已经在保护的 - ① 传输加密:有,全站 HTTPS / WSS(deploy/Caddyfile) - ② 存储加密:没有。数据库、附件存储都是明文存(只有 AI 分身的 API key 单独加了密 —— workroom/secretbox.go) - 手机本地缓存加密:没有(Hive 没开加密,app/lib/data/local_store.dart:87;docs/chat.md 里 CHAT-06 待办) - 端对端:没有。docs/LINKED_DEVICES.md:97 写着「没有端对端,界面上别这么说」;docs/GHOST_ROOMS.md:118 把幽灵房端对端列为终局 P3

好消息:幽灵房已经不进搜索、不做链接预览、不打暖度分、不叫 AI 助手 —— message/service.go:455-474。也就是说端对端最先在幽灵房试,几乎不会弄坏别的功能。

我们能走的三条路

A · 先补看不见的两层(现在就能做,AI 完全不受影响)

• 数据库、附件存储开存储加密;手机本地缓存加密(CHAT-06)
• 挡的是:服务器硬盘 / 备份被偷、手机丢了被人翻缓存
• 挡不了:能登服务器的人。所以界面上不许写「端对端」,只能说「传输与存储加密」
• 工作量:小到中;用户感觉不到任何变化

B · 「加密房」开关(像 Messenger 早期 / Telegram 秘密聊天)

• 在私聊或小群里点「开启端对端加密」→ 这间房从此只在成员手机上加解密,服务器只转发乱码
• 协议:用成熟库,不自己写(铁律 9)—— 一对一用 Signal 协议(libsignal),群用 MLS(IETF 标准,群加密现在的正解)
• 这间房里:搜索只在本机、锁屏通知只写「你有一条新消息」(或者用 iOS 的通知扩展在手机上解开再显示)、链接预览由发送方手机自己抓、个人 AI 助手 / 房间 AI / 暖度 / 援兵 AI 读房默认都不读
• AI 还能怎么用:学 WhatsApp —— 用户在这间房里主动 @AI,只把那一句(和他明确选中的几条)交给 AI,屏幕上明说「这一条会交给 AI」。是用户自己按次授权,不是 AI 一直在旁边看
• 第一批:幽灵房(它本来就不进 AI 和搜索,改动最小);再开放给私聊
• 工作量:大。最难的是钥匙,见下面「难点」

C · 终局:默认端对端 + AI 在手机上 / 在可信服务器上(观望)

• 像 Apple:AI 尽量在手机上跑(小模型),跑不动的送到「不留存、可审计」的特制服务器
• 现在不建议:成本高、周期长,而且我们的 AI 功能(援兵读房、工作房派活)本来就是为了让 AI 读设计的

推荐:A 现在做 + B 从幽灵房开始;C 等 B 跑顺再看。 工作房 / 援兵房不要加密 —— 那里 AI 读房就是功能本身。

难点(B 必须先想清楚的)

1. 多设备的钥匙:同一个人有手机 + 网页版 + 可能两台手机,每台都要有钥匙;网页版扫码登录时怎么把钥匙安全地交过去(docs/LINKED_DEVICES.md)
2. 换手机 / 丢手机:钥匙只在手机上 → 换手机旧聊天就没了。要么接受(像 Signal),要么做「用密码加密的钥匙备份」(WhatsApp 的端对端备份就是这样)
3. AI 分身也是「设备」:援兵 AI 读房要钥匙 —— 给了钥匙就不再是「只有人能看」。所以加密房里不放 AI 分身
4. 推送:锁屏预览要么不带内容,要么在手机上解开(iOS 通知扩展)
5. 举报 / 风控:服务器看不到内容 → 只能靠用户主动把那几条当证据交上来(我们现在的举报本来就是用户自己上传截图)
6. 撤权:有人被踢出群,之后的消息要换钥匙(MLS 自带这个)
7. 合规:某些地区对端对端有要求,上线前要问一下

要你定的三件事

1. 走 A + B 吗?(A 现在就做;B 先出详细设计再开工)
2. 加密房里 AI 的规矩:默认完全不读 + 用户主动 @AI 按次交给它 —— 同意吗?
3. B 第一批开在哪:只幽灵房 / 幽灵房 + 私聊 / 别的?