GitHub推荐：第一个删掉「你」的 messenger：14K stars 的 SimpleX Chat 用 6 年回答了 E2EE 解决不了的问题

GitHub: https://github.com/simplex-chat/simplex-chat

一句话总结

SimpleX Chat 是第一个在协议层彻底消除任何用户标识符（无手机号 / 邮箱 / 用户名 / 随机 ID）的开源端到端加密即时通讯平台——连服务器都无法绘制「谁在和谁说话」的社交图，结构性破解了端到端加密解决不了的元数据问题。

值得关注的理由

• 范式级差异，不是渐进改良：Signal/Matrix/Briar 都在「如何保护消息内容」层面优化；SimpleX 反其道，直接把「用户身份」这个字段从协议里删掉，从根上消除应用层 identity。这是一个值得所有 messenger 设计者重新思考的范式。
• 技术堆栈罕见且扎实：Haskell（协议核心 21.3%）+ Kotlin（Android 22.3%）+ Swift（iOS 17.3%）+ TypeScript（SDK 3.5%）四语言异构，FFI 边界设计为教科书级；后量子加密（sntrup761）比 Signal PQXDH 更激进。
• 6 年持续高活跃、审计齐全：14,930 stars / 863 forks / 6,183 commits / 82 贡献者 / 6 个大版本；2 轮 Trail of Bits 独立审计；Privacy Guides / Whonix / Heise 独立推荐；商业化路径清晰（v6.5 Consortium + 众筹）。

项目展示

配对流程：扫码或一次性邀请链接建立连接，全程不交换用户 ID

终端版 CLI 演示连接建立（已 verified）

加密聊天视图（来自官网）

端到端加密视频通话（来自官网）

Trail of Bits 2022/2024 两轮独立审计通过

Privacy Guides 列入推荐 messenger（与 Signal/Briar 并列）

项目画像

维度	数据
GitHub	https://github.com/simplex-chat/simplex-chat
Star / Fork	14,930 / 863（116 watchers）
代码行数	376,237 行（Kotlin 22.3% · Haskell 21.3% · XML 21.1% · Swift 17.3% · TypeScript 3.5% · Python 2.1% · 其他 19.5%）
文件数	2,270 个，12 种语言，注释率 19.5%
项目年龄	78.3 个月（2019-12 → 2026-06）
总提交 / 贡献者	6,183 commits / 82 贡献者
开发阶段	密集开发（近 90 天 266 commit ≈ 3/天，年化 800 commit）
贡献模式	强创始人 BDFL + 紧密小团队 + 80 社区贡献者（Top 1 占 35.7% 本地 / 55% API）
热度定位	大众热门（隐私工具圈头部；Telegram/Signal 替代品话题下高频引用）
License	AGPL-3.0（强 copyleft，阻止闭源分叉）
最新版本	v7.0.0-beta.2-armv7a / v6.5.6 stable
大版本节奏	v1.0(2022-01) → v2(2022-05) → v3(2022-07) → v4(2022-09) → v5(2023-04) → v5.7(2024-04 PQ) → v6.0(2024-08 Private Routing) → v6.1(2024-10 ToB 审计) → v6.5(2026-04 Public Channels) → v7.0(2026-06 beta)
多端覆盖	Android (Kotlin/Compose) + iOS (Swift/CallKit) + Desktop (Kotlin Multiplatform) + CLI (Haskell/TUI) + CLI lib + Node.js binding + TypeScript SDK + 5 个 bot 框架 + Directory 微服务 = 12 个目标平台/产物
质量评级	代码 9 / 文档 9 / 测试 8 / 多端 10 / 综合 9.0/10

作者视角：为什么存在这个项目

创始人/作者背景

Evgeny Poberezkin（epoberezkin，3,343 commits / 55% GitHub API / 35.7% 本地）—— 项目 BDFL + Haskell 协议核心架构师。英国开发者，此前在 .NET / Node 生态活跃，2020 年成立 simplex-chat Organization（背后是 SimpleX Network Ltd，英国非营利公司）。他在 poberezkin.com 博客的「Why privacy needs to be redefined」系列（2022-12）系统论证了 E2EE 在 MITM 下的脆弱性，自然推导出「信道的两端必须没有持久身份」。这不是工程团队的偶然发现，而是对 Signal / X3DH 信任模型的学术反思。

核心小团队：spaced4ndy（1,456 commits，移动端 / 多平台）+ Stanislav Dmitrenko（786 commits，推测 Android/KMP）+ JRoberts（470 commits，推测 iOS/Swift）+ Diogo（263 commits，推测 iOS/CallKit）+ 80 名社区贡献者做长尾补充。

问题判断

现有 messenger 在「端到端加密」上堆栈已经足够厚（Signal Double Ratchet、MLS、Noise Protocol……），但**加密解决不了「谁在和谁说话」**这个元数据问题：

• Signal/WhatsApp 用手机号 → 强可关联真实身份 → SIM swap 攻击、SIM 卡克隆
• Matrix / XMPP 用 DNS 命名空间（@user:server） → 服务器侧可见全网拓扑，单一服务器被攻陷即暴露某域下所有用户关系
• P2P 方案（Briar / Cwtch） → 用 DHT 寻址存在 Sybil / DRDoS 风险，且不支持异步离线消息
• Tor → 只解决 IP 元数据，不解决「应用层会话相关性」（同一 TCP 连接上对多个队列的操作可被关联）

Evgeny 在 v1（2022-01）之前探索过 Pond 设计（「SimpleX design can be seen as an evolution of Pond design」），把 Pond 的「代理 P2P + 无用户 ID」抽象引入到「双向 SMP 队列 + 双棘轮」中，再用 DJB 的 NaCL / cryptobox 落地。时机选择也踩得准：2021-2022 欧美对加密政策施压 + 后量子 NIST 标准化窗口，v5.6（2024-03）即把 sntrup761 正式合入双棘轮。

解法哲学

• 反 P2P 哲学：SimpleX 显式拒绝 DHT/纯 P2P 范式（docs/SIMPLEX.md L82-92 列举 P2P 的 6 项弱点），改用「proxied peer-to-peer」——每用户多组冗余单向队列，接收方可独立选 relay；
• 不试图打败 Signal 的多设备 UX，而是把它降级为隐私权衡：「You cannot use SimpleX Chat profile on more than one device at the same time — the encryption scheme rotates the long term keys」（blog/20240314）—— 接受「多设备同步必须破坏 break-in recovery」，把隐私绝对化；
• 显式放弃「public channels 也要 E2EE」的教条：docs/protocol/channels-overview.md 写明「public channels must be considered completely public」是产品决策、不是技术限制——因为任何通过 public link 加入的频道内容已是公开的（对抗 LLM 自动化爬取 = 0 成本），E2EE 没有意义，反而让 relay 运营方无法做内容管理；
• 典型的取舍：可选 temporary user address（docs/SIMPLEX.md L43）— 出于 spam 防护的妥协，但默认仍以一次性邀请链接 / 二维码为主。

战略意图

• 基础设施 + 商业产品双轨：SimpleX Chat Ltd（英国）做客户端（v6.5 启动 Consortium 治理 + 商业聊天 v6.2 + Public Channels 商业化）；simplexmq 仓库做 relay server + 协议；TypeScript SDK + Bot 框架面向第三方。
• 开源策略：「genuinely open」（AGPL-3，README L4 + LICENSE），协议公开并「will remain in public domain」（README L142），把 SimpleX 推成「自由言论基础设施」而非「客户成功故事」。
• 商业护城河：v6.5 启动 SimpleX Network Consortium + non-profit foundation（blog/20260430），把 SimpleX 从「Evgeny 公司」转成「公共物品」；2026-04 起准备 Reg CF crowdfunding。这是 2026 年 SimpleX 最大的战略变化——从开源软件过渡到「开源网络」形态。

核心价值提炼

创新之处

1. 「冗余单向 SMP 队列」作为 user-ID 替代品（新颖 5/5 · 实用 5/5）

   • 每对联系人 = 一对独立单向 SMP 队列；每队列有独立 QueueId + 独立 sender/recipient 凭证；DH 重加密保证同一队列在 forward / destination 两个 relay 看不到相同密文。
   • 落地位置：src/Simplex/Chat.hs 主控 + simplexmq 协议白皮书「redundant simplex queues」章节。
   • 适用：任何想消除应用层 identity 的 messaging / collaboration / signaling 系统。

2. 「双棘轮 + sntrup761 KEM lock-step」（新颖 5/5 · 实用 4/5）

   • KEM 天然不对称（封装者用接收者 pubkey），不适合双棘轮的对称 ratchet step；SimpleX 让双方各发一个 KEM pubkey + 各封装一个 shared secret，互为密钥；每轮 ratchet step 同时更新 DH 私钥 + KEM 私钥。
   • 关键点：选 sntrup761（NTRU Prime）而非 NIST ML-KEM（Kyber）——Evgeny 在 blog/20240314 L176 公开批评 NIST 移除 Kyber 哈希步骤，主动与 Signal PQXDH / Apple PQ3 分道扬镳。
   • 落地位置：Messages/CIContent.hs:184 的 E2EInfo{pqEnabled} 字段 + Store/Shared.hs:228-365 的 PQSupport/PQEncryption 列 + M20240228_pq.hs 迁移。
   • 适用：任何想给 Signal 双棘轮加 PQ 而不被 Kyber 的密钥大小撑爆的 messenger。

3. 「Private Routing = sender-chosen forward relay + recipient-chosen destination relay」（v5.8, 2024-06）（新颖 4/5 · 实用 4/5）

   • 2-hop onion 但 hop 选择权被双向分摊 → 既避免 Tor 单一 entry guard 长期关联，又避免传统 VPN 单一 exit 暴露。
   • 落地位置：blog/20240604-private-message-routing... L66-83 完整 ASCII 图（e2e + s2d + f2d + d2r + TLS 五层）；blog/20241014 描述默认开启策略。
   • 适用：email / XMPP / Matrix 客户端想给已有协议加 sender-IP 保护。

4. 「Public Channels 显式不 E2EE」（v6.5, 2026-04）（新颖 4/5 · 实用 5/5）

   • docs/protocol/channels-overview.md L96-104 表格与 Telegram / Nostr / Signal / Matrix / Mastodon 全面对比；Channel identity = SHA256(genesis root Ed25519 pubkey)，Owners 持有私钥 + 多 relay 冗余；订阅者用独立 SMP 队列，relay 看不到订阅者 IP。
   • 与 Telegram「中央服务器」模型相反（无单一权威可下架频道）；与 Nostr「单 pubkey 一切」相反（无串号/follow 列表泄露）；与 Matrix room「绑 creating server」相反。
   • 适用：任何想建「公开订阅 + 私密身份」的 RSS / newsletter / podcast 系统。

5. 「FK 双层 + StablePtr ChatController」的 FFI 边界设计（新颖 3/5 · 实用 5/5）

   • src/Simplex/Chat/Mobile.hs（388 行，27 个 foreign export ccall 符号）把 1,793 行 Controller.hs 完整 170+ ChatCommand + 250+ ChatResponse 暴露为 JSON-over-CString；客户端句柄用 StablePtr 而非 raw pointer（GC 安全）；defaultMobileConfig 与 CLI defaultChatConfig 同一份 Haskell 配置，差异化只在 Mobile.hs:245-287 的 mobileChatOpts。
   • 落地位置：Mobile.hs:108-154（Haskell）+ apps/multiplatform/common/src/commonMain/kotlin/chat/simplex/common/platform/Core.kt:18-40（Kotlin）+ apps/ios/SimpleXChat/API.swift:24-54（Swift）。
   • 适用：任何「核心算法 Haskell/Rust + 多端原生 UI」项目。

6. 「命名迁移作为 schema evolution code review 对象」（新颖 3/5 · 实用 5/5）

   • 每个迁移 = M<YYYYMMDD>_<snake_case>.hs 单文件（如 M20260516_supporter_badges.hs），含 up / down 两个纯 SQL 字符串；Store/SQLite/Migrations.hs 是单一 registry；review 时只看新增文件 + 修改的单一 registry。
   • 4 年累计 160+ 命名迁移，覆盖 SQLite（默认 / sqlcipher 加密）+ Postgres（client_postgres cabal flag）双后端。
   • 适用：任何有「客户端+服务端+企业版」三轨 schema 的产品。

7. 「ServerOperator + UsageConditions + ConditionsNotified」的商业化合规抽象（新颖 3/5 · 实用 4/5）

   • 第三方 relay 进入 App 预设列表必须维护 PRIVACY.md（Operators.hs:62-72 用 TemplateHaskell embedFile 编译进 binary），并被用户首次启用时显式接受（APIGetUsageConditions / APISetConditionsNotified / APIAcceptConditions）。
   • 落地位置：Chat.hs:82-104 内置 SimpleXChat + Flux 两家 preset。
   • 适用：邮箱 / DNS / VPN 类「聚合多家后端的客户端」。

8. 「Channel identity = SHA256(genesis root Ed25519 pubkey)」（新颖 4/5 · 实用 4/5）

   • channels-overview.md L153：频道身份永久绑定到 genesis root 私钥；订阅者收到频道链接后自我验证 hash；任何后续 relay 增删都不改身份。
   • 适用：Patreon / Substack / RSS 想做「作者主权 + 不可被平台封禁」时。

可复用的模式与技巧

1. JSON-over-CString FFI 桥接（src/Simplex/Chat/Mobile.hs:108-154）—— Haskell core 用 StablePtr ChatController 暴露给原生客户端，所有命令/响应序列化 JSON。任何 Haskell/Rust 核心 + 多端原生 UI 项目都可以直接借鉴。
2. 命名迁移作为 schema evolution 一等公民（src/Simplex/Chat/Store/SQLite/Migrations/M*.hs，160+ 文件，4 年）—— 任何长期演进的产品（4 年 160+ 迁移是教科书级）。
3. TVar/TMap + ReaderT 的 Haskell 状态机（Chat.hs:150-251 newChatController 一次性创建 30+ TVar/TMap/TMVar 做 in-memory state）—— Haskell 长生命周期应用的状态管理。
4. DualStore 抽象（chat + agent 双 DB）（Chat.hs:144-148 createChatDatabase 同时初始化 chatStore + agentStore）—— 分离「协议层 DB」与「产品层 DB」的项目。
5. PresetOperator + ConditionsNotified 的 SaaS 后端聚合（Chat.hs:82-104 + Operators.hs:62-72）—— 任何想聚合多家 SaaS 后端的客户端（邮箱 / DNS / VPN）。
6. 固定 16KB block + zstd 压缩（Chat.hs:114 fileChunkSize = 15780，注释「do not change」）—— 任何想对抗 traffic analysis + 同时省流量的 messaging / file transfer 系统。
7. ChatHooks 作为扩展点（Controller.hs:189-200 让 CLI 与 Mobile 在同一份 ChatController 上差异化）—— 同一份核心库 + 多个客户端（CLI / Mobile / Bot）共用。
8. Bots 复用 library 而非 fork（simplex-chat.cabal:371-449 暴露 5 个 executable：simplex-bot / simplex-bot-advanced / simplex-broadcast-bot / simplex-directory-service / simplex-support-bot）—— 需要快速衍生产品而不分叉核心代码的组织。

关键设计决策

决策	问题	方案	Trade-off
冗余单向队列替代 user ID	协议层无 ID 又要支持异步离线	每对联系人 = 一对 SMP 队列 + 独立凭证 + DH 重加密	丧失全局寻址 → 邀请链接/二维码/临时 address bootstrap；服务器必须内存中保留每队列状态
5 层加密 + 16KB 定长 block	保护消息内容 + 元数据	双棘轮 + s2d/f2d/d2r/TLS + 定长填充	大消息必须切片；zstd 压缩腾空间；开发复杂度 ≫ Signal
Haskell chat core + FFI C ABI	跨 4 平台共享协议	StablePtr + JSON-over-CString 暴露 27 符号	JSON 序列化开销 + 失去类型安全；foreign export 符号名稳定成硬契约
sntrup761 而非 NIST ML-KEM	Shor 算法威胁	双 KEM lock-step（双方各发 pubkey + 互封装）	与 Signal/Apple PQ3 生态分叉；需 2.2KB block 余量
Private Routing (v5.8)	隐藏 sender IP	2-hop onion + 双向选 hop + 临时密钥	需双向都升级 v5.8+；~30% 延迟 + relay CPU 成本
Public Channels (v6.5) 显式不 E2EE	公开内容 E2EE 无意义	Channel identity = SHA256(root pubkey)	失去内容机密性，换取参与者不可关联
PresetOperator + ConditionsNotified	第三方 relay 进 App 保护用户	商业化合规抽象	商业合规成本（Flux/自建必须维护 conditions）
SQLite + Postgres 双后端 + 160+ 命名迁移	手机本地加密 + 企业自部署服务端	cabal flag 切换 + 每文件一改	每条 SQL 必须对两套方言都生效；新功能必须同周双写迁移

竞品格局与定位

竞品对比矩阵

维度	SimpleX Chat	Signal	Matrix / Element	Briar	Session (Oxen)
用户标识符	❌ 无（协议层）	📱 强制手机号	🆔 @user:server	📡 无（但仅 P2P）	🆔 Session ID（onion）
端到端加密	✅ Signal 双棘轮 + sntrup761 PQ	✅ Signal 双棘轮 + PQXDH	✅ Element room-level	✅ Noise Protocol	✅ X25519 + onion
服务器可见社交图	❌ 看不到（per-queue）	⚠️ 看到（手机号簿）	⚠️ 看到（联邦拓扑）	✅ 无服务器	⚠️ 看到（Session ID）
多设备同步	❌ 显式禁止（保护 break-in recovery）	✅ 4 设备	✅ 联邦多端	❌ 单端	✅ 加密云备份
抗审查强度	⭐⭐⭐⭐（Private Routing v5.8）	⭐⭐	⭐⭐⭐（联邦）	⭐⭐⭐⭐⭐（Tor hidden service）	⭐⭐⭐⭐（onion routing）
跨平台覆盖	✅ Android+iOS+Desktop+CLI+SDK	✅ Android+iOS+Desktop	✅ 全平台	❌ 仅 Android	✅ Android+iOS+Desktop
公开频道	✅ Public Channels v6.5（不 E2EE）	⚠️ 群组（E2EE）	✅ 公开 room（E2EE）	❌	⚠️ 群组（onion）
独立审计	✅ Trail of Bits 2022/2024	✅ 多次（NCC/Cure53/…）	✅ Element / NCC	✅ Guardian Project	✅ QUAE/Auditless
项目年龄	6.5 年	12+ 年	10+ 年	7+ 年	6+ 年
GitHub stars	14,930	~67,000	~12,000	~2,500	~5,500
共识开销	无（去中心化但不需要 blockchain）	无（中心化）	无（联邦）	无（纯 P2P）	有（Oxen 链）
协议规范公开	✅ AGPL-3 + 70+ RFC	❌（客户端闭源）	✅ Apache 2.0	✅ MPL-2.0	✅ GPL-3

差异化护城河

• 技术护城河：双棘轮 + sntrup761 + 2-hop onion + 16KB block + redundant queues = 5 个独立创新点堆叠，竞品很难快速复制
• 协议护城河：协议 + 白皮书 + 70+ RFCs 公开（docs/rfcs/），实现可第三方审计
• 治理护城河：v6.5 启动 Consortium + non-profit foundation（blog/20260430），把 SimpleX 从「Evgeny 公司」转成「公共物品」——Signal/Matrix 都不可能走这步
• 可复现性护城河：493 次更新 scripts/nix/sha256map.nix + reproduce-schedule.yml workflow + simplex-chat-reproduce-builds.sh 脚本——「用户运行的二进制 = 公开源码编译」的强实践，对隐私工具的可信度至关重要

竞争风险

• Signal PQXDH + Triple Ratchet（2023-11 / 2024-09）→ 长期看会消除 PQ 差距
• Apple iMessage PQ3（2024-02）→ 已用 Kyber + X25519 混合，在 iOS-only 用户群可能抢占 SimpleX 位置
• Matrix 的「联邦 + E2EE by default」 → 如果跑通，SimpleX 的「无 ID」卖点会被稀释
• UX 短板：issue #444「Multi-device synchronization」开了 4 年仍未合（71 评论），issue #1821「Battery Optimisation」65 评论——Haskell + FFI + 多平台架构的工程代价

生态定位

SimpleX 不是替代 Signal 的「更好 messenger」，而是面向高威胁模型的 protocol-level privacy utility。其真正可比对象是 Tor（基础设施层），不是 Telegram（应用层）。SimpleX 自己也明说：目标用户是「记者/维权人士/对去中心化协议感兴趣的开发者」，消费级 Signal 用户是错位次要目标。

套利机会分析

• 信息差：SimpleX 在英文隐私圈已热（Privacy Guides / Whonix / Heise / Wired / Guardian 广泛报道），但中文圈认知度极低——国内公众号几乎没有深度分析 SimpleX 的多设备同步工程难题、Consortium 经济模型、量子抗性双棘轮实现等核心议题。这是「被英文圈热捧 / 中文圈科普度不足」的典型认知差，公众号选题价值高。
• 技术借鉴：
  • FFI 边界设计（Mobile.hs:108-154）→ 任何「核心算法 Haskell/Rust + 多端原生 UI」项目
  • 命名迁移（M*.hs）→ 任何长期演进的产品 schema 管理
  • PresetOperator + ConditionsNotified → 任何聚合多家 SaaS 后端的客户端（邮箱/DNS/VPN）
  • redundant simplex queues 抽象 → 任何想消除应用层 identity 的 messaging/collaboration 系统
• 生态位：
  • 隐私 messenger 圈的「结构性创新者」——不是渐进改良，而是对 messenger 范式做了一次底层重定义
  • 「无 user ID」 这条赛道目前几乎独家——Signal/Matrix/Briar 都在另一条赛道
  • 大模型时代的反爬叙事——Public Channels 显式不 E2EE，反 E2EE-by-default 教条，对 LLM/爬虫时代的 RSS/newsletter/podcast 产品有直接借鉴价值
• 趋势判断：
  • 2024-08 Pavel Durov 被捕后 Telegram 用户迁移报道 → SimpleX 受益（近 100 个 stargazer 集中在 ~3 天内）
  • 后量子加密标准化窗口期 → SimpleX 已 BETA 走在 Signal 前面
  • 6.5 年 + 6 个大版本 + 80 贡献者 + 14k stars + 2 轮独立审计 → 健康持续 + 后劲足
  • v6.5 Consortium + v7.0 beta → 正在从「开源软件」过渡到「开源网络」形态

风险与不足

• BDFL 风险：Evgeny 占 55% commit，强中心化决策 → 任何重大路线调整都依赖他个人判断
• 多设备 UX 硬伤：issue #444 4 年未合，显式牺牲多设备换 break-in recovery——对消费级用户是劝退点
• 功耗问题：Haskell + FFI + 多平台架构的天然代价（issue #1821 65 评论）；移动端体验对比 Signal 仍有差距
• 生态规模小：14,930 stars 对比 Signal 67,000 + WhatsApp 数十亿；典型两难——隐私特性强 + 用户基数小 → 网络效应差
• 极端组织迁移风险：Wired 2024-09 / Guardian 2024 报道 far-right + IS 等极端组织利用该平台（项目方在博客中反驳「Wired’s Attack On Privacy」）→ 对项目声誉是真实存在的外部风险
• 测试覆盖率偏低：4% 估算（按 hot_dirs 推算），对 Haskell 项目属合理但仍有提升空间
• PG 推送依赖（issue #1081）：Android 推送链路对 Google FCM 的依赖是「用户主权」叙事的硬伤

行动建议

如果你要用它

• 适用场景：高威胁模型通信（政记/律师/受监控人群）、跨平台小群体协作、自托管隐私社群、对服务器可见性零容忍的开发者
• 对比竞品说明：
  • 比 Signal：换「无手机号 + relay 不存消息 + PQ 已合入」→ 适合不愿暴露手机号 + 想让服务器彻底看不到元数据的用户
  • 比 Matrix：换「无 user ID」→ 适合不愿在任何联邦服务器留有持久身份的用户
  • 比 Briar：换「iOS+Desktop+大文件+异步可达」→ 适合需要跨平台 + 不止 Android 的用户
• 使用前须知：必须放弃多设备同步、放弃手机号通讯录关联；联系人必须逐个建立新连接

如果你要学它

重点关注以下文件/模块（按学习价值排序）：

1. src/Simplex/Chat/Mobile.hs（388 行）—— FFI 边界设计的完整范本，27 个 foreign export ccall 符号 + JSON-over-CString + StablePtr 句柄 + ChatHooks 扩展点
2. src/Simplex/Chat.hs（328 行）—— ChatController ctor 创建 30+ TVar/TMap/TMVar 的状态机范式
3. src/Simplex/Chat/Controller.hs（1,793 行）—— 170+ ChatCommand + 250+ ChatResponse + ChatEvent 的 sum type + Aeson TemplateHaskell JSON 派生范式
4. src/Simplex/Chat/Store/SQLite/Migrations/M*.hs（160+ 文件）—— 命名迁移 + schema evolution 一等公民的工程文化
5. docs/SIMPLEX.md + docs/protocol/channels-overview.md + blog/20240314-quantum-resistance-... + blog/20240604-private-message-routing... —— 协议层 + 设计哲学的完整白皮书
6. Operators.hs + Chat.hs:82-104 —— PresetOperator + ConditionsNotified 的 SaaS 后端聚合范本
7. cabal.project + scripts/nix/sha256map.nix + reproduce-schedule.yml —— 强可复现构建的工程承诺
8. simplex-chat.cabal:371-449 —— 1 个 library + 5 个 executable + 1 个 test-suite 的产品衍生模式

如果你要 fork 它

可改进的方向：

1. 多设备同步方案（issue #444，4 年未合）—— 这是一个「无 ID 范式 + break-in recovery」 trade-off 的研究前沿，可能产出创新论文
2. 降低移动端功耗（issue #1821）—— Haskell 守护进程在 Android/iOS 的功耗优化是个独立的工程问题
3. 脱钩 Google FCM（issue #1081）—— UnifiedPush 集成或自建推送中继，对「用户主权」叙事是补全
4. Public Channels 客户端 UX（v6.5 新功能）—— 现在 channels 还在协议层打磨，客户端体验有大把改进空间
5. AI 时代的反爬保护（v6.5 public channels 显式不 E2EE 的延伸）—— LLM 自动爬取时代，「公开内容 + 反自动化消费」是个独立产品方向
6. 企业版自托管 UI（Postgres 后端 + Operator 服务）—— 现在自托管需要命令行，对企业 IT 友好度不够

知识入口

资源	链接
DeepWiki	https://deepwiki.com/simplex-chat/simplex-chat — 已收录（覆盖 architecture / protocol / storage / FFI bridge / iOS Swift 状态管理 / Android Compose / Build & CI）
Zread.ai	未收录（403）
关联论文	协议规范在仓库内（非 arXiv 论文形式）： • SimpleX Whitepaper: https://github.com/simplex-chat/simplexmq/blob/stable/protocol/overview-tjr.md • SMP Protocol: https://github.com/simplex-chat/simplexmq/blob/stable/protocol/simplex-messaging.md • Chat Protocol: https://github.com/simplex-chat/simplex-chat/blob/stable/docs/protocol/simplex-chat.md • Channels Design: https://github.com/simplex-chat/simplex-chat/blob/stable/docs/protocol/channels-overview.md
Trail of Bits 审计	2022-11 完整审计: https://simplex.chat/blog/20221108-simplex-chat-v4.2-security-audit-new-website.html 2024-10 加密设计审查: https://simplex.chat/blog/20241014-simplex-network-v6-1-security-review-better-calls-user-experience.html
关键博客	• v6.5 Channels + Consortium: https://simplex.chat/blog/20260430-simplex-channels-v6-5-consortium-crowdfunding-freedom-of-speech.html • 后量子双棘轮: https://simplex.chat/blog/20240314-quantum-resistance-signal-double-ratchet-algorithm.html • Private Routing: https://simplex.chat/blog/20240604-private-message-routing-chat-themes.html • 重新定义隐私: https://simplex.chat/blog/20240516-redefining-privacy-by-making-hard-choices.html
在线 Demo	官方提供 CLI 客户端 + 可自建 SMP/XFTP/WebRTC 服务器（无 hosted demo）