仓库缺少 LICENSE，想确认许可条款后再提交贡献

[magicapple123]

仓库缺少 LICENSE，想确认许可条款后再提交贡献

先说这个问题

仓库当前没有 LICENSE 文件（GitHub API 的 license 字段为 null）。

按默认著作权规则，没有许可证 = 「保留所有权利」。严格来说，别人（包括我）没有法律依据
去复制、修改、分发这份代码 —— 即使在 GitHub 上开 PR 这种协作形式，也是在默认授权框架下
才顺理成章。README 里写了「欢迎 PR」，但那是一句期望，不构成许可条款。

这会影响的不只是外部贡献者：

• 想提 PR 的人不知道自己写的东西会以什么条款分发出去；
• 想在自己公司内部部署的人不确定是否合规；
• 你们将来如果打算接受外部代码，没有明确的 inbound 许可声明（CLA / DCO / 或直接
  声明 inbound=outbound）会留下隐患；
• 如果哪天要用更严格或更宽松的条款重新发布，追溯历史贡献会很麻烦。

所以想先问一句：你们计划给仓库加一个许可证吗？如果加，倾向于哪个？

我个人建议 MIT 或 Apache-2.0 —— 这类本地工具项目最常见、对使用者最友好，
而且能立刻消除上面这些问题。如果你们倾向于别的条款（GPL、AGPL 或保留部分权利），
也完全没问题，只要明确下来就行。

只要许可证明确了，我这边随时可以按需要把下面几个贡献点拆成独立 PR 提上来。

我打算贡献什么

我在做 Windows 微信 4.x 聊天记录查看/导出/分析方向的开发，交叉对比过若干开源方案，
其中就包括这个项目。三层架构（native core + FastAPI 后端 + Vue 前端）分得很干净，
微信原生转写与本地 Whisper 双路线、账号维度的缓存与并发模型都做得比我见过的大部分方案好，
所以想反过来把我在自己项目里已经稳定运行、而这边还缺的东西贡献回来。

贡献点一：演示数据库种子脚本（最独立，建议先合）

仓库里已有的 tools/seed_ai_acceptance.py 生成的是明文 SQLite，而真实链路是 WCDB 加密的。
我写的 tools/seed_demo_database.py 生成的是真正按 WCDB/SQLCipher 页格式加密的演示账号，
可以直接跑通从「扫描账号目录」→「解密」→「读取」的完整链路。

两个刻意的设计：

1. 不硬编码加密常量，而是 import 上游自己的 PAGE_SIZE / RESERVE_SIZE /
   _derive_sqlcipher_enc_key / _compute_page_hmac。这样上游改加密格式时，
   脚本会跟着一起失效，而不是悄悄产生错误数据 —— 我认为这一点比脚本本身更重要。
2. 数据全是虚构的（wxid_demo_2026、昵称统一带「示例」、链接一律 example.com），
   覆盖单聊/群聊、文本/链接卡片/转账/系统提示/引用消息。
   用途是给测试、截图、新贡献者上手提供一个不含真实隐私的起点。

自校验实测（用上游自己的解密器）：Page 1 HMAC verification passed、
successful_pages=7 failed_pages=0、reserved_space=80、自校验通过：成功解密 2/2。

涉及文件：tools/seed_demo_database.py、tests/test_seed_demo_database.py（5 项）、
docs/demo-database-seed.md。不碰任何产品逻辑，输出默认落在已在 .gitignore 的 output/demo/。

贡献点二：多协议云端语音识别适配器（engine="cloud"）

现在识别只有两条路：本地 faster-whisper（要下 75 MB ～ 3.1 GB 模型 + 占 CPU/GPU）
和微信原生（依赖微信客户端在线）。两种情况覆盖不到：

• 机器性能有限，本地跑一条语音要等十几秒；
• 只想偶尔转写少量语音，不值得为它下模型、装 CUDA 运行库；
• 手上已经有 OpenAI 兼容 / 阿里云百炼的额度，想直接复用。

我把它做成可替换的后端，支持三类协议：
openai_compatible（/audio/transcriptions multipart）、
dashscope_asr（/chat/completions + base64 input_audio）、
custom_multipart（字段名/请求头/响应路径全可配置）。

几个关键取舍：

1. 默认不联网。 没配 base_url 时构建返回 None，所有既有路径行为完全不变。
2. 缓存与本地路线共用。 复用同一张 transcript 表和同一套取音频/SILK 解码逻辑，
   只有 model 字段写成 cloud:<protocol>:<model> 做隔离。所以本地跑过的切云端
   不需要重新识别 —— 这点我认为比另起一套缓存重要得多。
3. 不申请本地模型活动租约（云端路线完全不加载模型）；并发默认 3、上限 8，
   因为瓶颈在服务商限流，不能按本地 CPU 并发推导，配成 64 会把账号打爆。
4. 微信原生已转写的语音直接跳过，避免重复付费。
5. 安全约束（要把用户语音上传出去，所以写得比较克制）：明文 HTTP 只允许回环地址；
   不跟随重定向（防 Authorization 头被转发给未知主机）；默认 25 MB / 硬上限 100 MB；
   错误信息不含本机路径、API Key 与响应正文；设置读接口永不回显 Key；
   配置落盘做白名单 + 长度限制 + 拒绝控制字符（手改 JSON 塞换行不能污染请求头）。

与 #151 的关系：我注意到 #151 正在改写语音转写这条路（批量入口、
SettingsDialog.vue、VoiceTranscriptionSidebar.vue、导出对话框的 exportTranscribeVoice）。
我刻意没有动那两个前端文件和 voice_transcription.py 里的识别逻辑，改动只限于
engine 白名单与分发这一层。所以这个 PR 建议等 #151 合入后我再 rebase 提交，
避免制造冲突。如果你希望更早看到代码，我也可以现在就提。

补充一句：项目里已有的 cdn_image_service.py 走第三方商业 CDN，和这个不冲突 ——
那条路依赖特定服务商的额度与兑换码，而这里是用户自己的接口地址与 Key。

贡献点三：批量高清原图自动化（想先问是否需要）

这个项目当前的高清图路线是商业 CDN。我自己项目里的做法不同：不依赖任何第三方服务，
直接在本地驱动微信客户端把聊天里的压缩图批量换回原图并归档。

但我在移植前想先确认价值：它依赖 Windows UI 自动化（热键、窗口句柄、资源监控），
移植成本不低且天然只支持 Windows，功能上和现有 CDN 路线有重叠。

所以想问：这个方向你们需要吗？ 如果重叠部分你们觉得没必要，
我可以只挑其中不依赖 UI 自动化的部分（原图资源的识别、去重与归档）单独提。

关于测试

我用 uv + Python 3.11 跑了完整测试集，并且改动前后逐项对比：

	测试数	失败	错误	跳过
基线（未改动）	2682	85	18	10
加上我的改动	2758	85	18	10

失败集合逐项比对完全相同（新增失败 0 项），新增的 76 项测试全部通过。

需要说明的是，上面的失败/错误在我这边本来就不是绿色，原因是环境缺件而非代码问题：

• test_native_core_export_decrypt.py、test_macos_manual_launch.py 等需要预编译的
  wechatdb_client.dll，仓库里没有，直接 error；
• 一批 macOS 用例在 Windows 上失败；
• test_voice_transcription_contract.py::test_export_option_is_wired_from_dialog_to_backend
  在基线提交上就是红的：exportTranscribeVoice 在 ChatExportDialog.vue 与
  useChatExport.js 里都不存在 —— 看起来正是 feat: 升级本地语音识别并修复小程序图片导出与 Windows 回归 #151 的 diff 在补的东西。

所以我描述自己改动的测试结果时都是和基线对比给的，没有把既有失败算进来。
如果你们的 CI 装了原生库，失败集会比上面小得多。

小结

1. 许可证：能给一个明确答复吗？这是我现在唯一的前置阻塞。
2. 贡献点一（种子脚本）：不碰产品逻辑、争议最小，许可证明确后我可以立刻提 PR。
3. 贡献点二（云端 ASR）：代码已完成并在 fork 上，建议等 feat: 升级本地语音识别并修复小程序图片导出与 Windows 回归 #151 后 rebase 再提。
4. 贡献点三（高清原图）：想先听你们意见，需要我再动手。

谢谢！

[2977094657]

恭喜你是第二个注意到许可证问题的人，首先生成演示账号数据这个目的是什么？什么场景？以及看起来3目前暂时不会被合并，因为我们已经做了改动了，4适配性就更差了，所以暂时都不考虑，不过还是感谢为开源生态做出贡献，或许后续你有更好的点子和功能也还原再次pr，说不定就会被合并

[magicapple123]

谢谢答复，也谢谢直接说清楚哪些暂时不会被考虑 —— 这比我继续投入之后才发现要好得多。

先把你的两个问题答了，因为我觉得回答它们可能比让这个 PR 被合并更有价值。

生成演示账号数据的目的和场景

起因很具体：我给自己项目做对外截图时卡住了。

我想展示「解密 → 聊天列表 → 消息渲染」这条链路，但手上只有真实微信数据。
拿真实数据截图是不可接受的（会话名、群名、消息正文、头像全是隐私），
而当时仓库里已有的 tools/seed_ai_acceptance.py 生成的是明文 SQLite，
它跑不了「扫码/输密钥 → 解密 → 读取」这一段 —— 那恰恰是最需要截图的环节。

所以我需要一份满足三个条件的数据：

1. 真的加密（逐页 AES-CBC + 逐页 HMAC 的微信 4.x 格式），否则驱动不了完整链路；
2. 表结构是真的（Msg_* 分表、Name2Id、contact.db 这些真实 schema），
   否则解析层会走不到真实分支；
3. 内容全是虚构的，可以公开。

具体场景有三个：

• 截图/文档/演示视频：用可公开的虚构数据展示界面，不用打码也不用担心漏隐私；
• 没有微信环境的贡献者：新人在 Linux/macOS 或干净机器上跑的时候，
  至少能验证「解密 → 解析」这段逻辑是通的；
• 回归测试的样本：需要「真实加密格式 + 真实表结构」的固定输入，
  这跟明文样本覆盖的能力不一样。

一个我必须说清楚的前提

不过你这一问让我意识到，这个脚本的价值高低，完全取决于你们是否需要它。
如果你们内部已经有等价的加密样本（比如私有仓库里放着真实导出物），
那它确实是重复劳动 —— 这种情况下我完全理解不合并。

另外有个客观限制我得坦白：它只覆盖我当初遇到的那部分 schema。
微信版本迭代很快，如果你们现在的表结构比我写的更复杂（比如新的分表规则
或字段），我这个脚本产出的数据可能不够"真"，需要跟着你们的现状调整。
这点我没法自己判断，因为我没有你们的测试数据集。

所以如果你的判断是"我们已经有了、或适配性不够"，那就是对的，不必勉强。
你如果愿意说一句你们现在怎么做加密样本的，我也能判断这个脚本还有没有调整的价值。

关于另外两点

你说 3（云端语音识别）和 4（高清原图）适配性更差、暂时都不考虑 ——
我看了下 #151 的描述（收敛到 Zipformer CTC、Qwen3-ASR 0.6B CPU/GPU、Whisper Turbo），
明白了：你们把我做的那个方向（多协议云端 ASR）已经用更贴自己架构的方式做掉了，
Qwen3-ASR 本身就覆盖了我适配器里的 DashScope 协议。高清原图那块，
我也确认了 cdn_image_service.py + chat_media.py 的 CDN 原图链路 + system.py
里的开关已经是完整实现。

这两块确实是重复劳动，我不再推进，两个分支我留在自己 fork 上就行。

关于许可证

你说我是第二个注意到的 —— 那说明这个问题已经存在一段时间了。
如果第一个人提了之后一直没有结论，我猜可能是你们有意保留全部权利
（比如和高级版/兑换码那套商业化设计有关）。如果是这样，
其实在 README 里明确写一句"本项目保留所有权利，不接受外部代码贡献"反而更省事，
能避免后面还有人白写代码 —— 我这次就是没找到任何声明才当成了开放项目。

当然如果只是还没顾上处理，那就当我没说。

最后

不管这个 PR 结果如何，你最后一句话我记下了：后续有更好的点子和功能可以再次提。
我也顺便把这次的经验用在自己项目上了 —— 之前我也没给我的仓库加 LICENSE，
刚刚去补上了，因为这次轮到我体会到"想贡献的人看到没有声明时的犹豫"是什么感觉。

再次感谢抽时间回复。

[2977094657]

在说一遍，不是不接受pr，可以看看我之前合并了多少pr，只是你当前的pr对我们没有实质性的帮助，我们实际上已经有隐私模式了，或许你可以朝着这个方向来改一下，结合到隐私模式里，使其多一个mock选项，总之看你交互设计，而不是这么大费周章的改这么多东西，关于许可证，这是故意设计如此，我不想更深解释为何我要这样设计，这可能会暴露一些东西