LINE 协议与 E2EE

负责与 LINE 通信的 @vyline/protocol 当前结构。

Device mode

Protocol 内部

VylineUpdater
  └─ DesktopProfile (UA / X-Line-Application / hosts)
        ↓
VylineClient
  ├─ patchDesktopTransport
  ├─ patchDesktopLogin
  ├─ ensureValidE2EEIdentity
  └─ TalkService / domain facade

@vyline/protocol 并不是薄薄一层 HTTP wrapper。device identity、login RPC、transport header/path、Letter Sealing E2EE、TalkService、Desktop 更新跟踪，以及对 Backend 暴露的 domain facade 都属于 Protocol 的职责。

登录

QR

loginWithQR → protocol stack → secure QR login。Desktop mode 下会把 systemName/modelName 调整为所选 device identity。

Email + E2EE

1. 取得 RSA key。
2. 执行 loginV2 / E2EE confirm。
3. 取得 keychain。
4. 保存本机 identity key。
5. 与 server 端最新 key 状态对齐。

Token

loginWithToken 恢复 access token 后，仍会检查 transport profile 与 E2EE identity。

Transport

Protocol 根据 Desktop 实测数据构造 user-agent、x-line-application、locale、host 与 RPC path。Profile 解析优先顺序为：运行中 Desktop 提取 → 已安装版本/OS 合成 → cache → fallback。

path 不是靠猜测“看起来像”的 endpoint 决定。应把 Protocol patch、RPC 字典与 Desktop 证据对应起来。怀疑 Desktop 更新改变 header/path 时，从 modules.map.ts 追踪关联 binary/string。

E2EE

登录前的旧历史，如果缺少当时使用的本机 identity key，可能无法解密。发送时也需要与 server 当前 keyId 对应的 private key，缺失时可能出现 sender-key update 类错误。

接收

1. 通过 Talk sync 取得 message operation。
2. 根据 message metadata 判断是否为 E2EE payload。
3. 解析自己、对方或群组所需 key，并解密 Letter Sealing payload。
4. Backend 将结果规范化为 UI message，并保存到账号专用 SQLite。

发送

1. 检查发送目标与当前 E2EE key 状态。
2. 需要时 warm/refresh group key 或 public key。
3. 加密 text 或 media metadata，经 Talk/OBS 路径发送。
4. 收到 sender key 更新请求时，重新获取 key 状态，并只通过允许的 retry 路径重试。

media binary 并不完全包含在 Talk message 中，还会经过 object storage。Protocol 的 RPC 字典包含 E2EE media upload/download 对应关系，Backend lineService 统一协调 message metadata 与 binary 处理。

Talk sync

Backend 的 clientManager 使用已登录 Protocol client 的 base.talk.sync 持续取得 operation。随后交给 lineService.processFetchedOperations，完成 decrypt、保存以及 Frontend event buffer 更新。

TalkService sync (/S4)
  ↓ operations
clientManager
  ↓
processFetchedOperations
  ├─ E2EE decrypt
  ├─ message/chat normalize
  ├─ SQLite persist
  └─ frontend event buffer

Domain facade

wrapSession(client) 包装已登录 Client，把 Profile / Contacts / Chat / Talk 作为按功能划分的 API 提供给 Backend。这一层避免 raw Protocol RPC 散布到整个 Backend。

Modules Map 与 RPC 字典

src/modules.map.ts 记录各功能关联的 source、Desktop binary、搜索字符串、analysis docs 与复查 priority。目前可按 feature 查 QR/Email login、transport、E2EE key/send/decrypt、Talk send、profile、chat admin、sync、stickers、calls 等。

src/dictionary/rpcMap.ts 按 RPC 对应 canonical name、Desktop evidence、path、stack API、domain API、Backend API、category 与 notes。添加功能时按下面顺序追踪，避免跨过层次。

Desktop evidence / RPC_DICTIONARY
  ↓
stack API (Thrift / transport)
  ↓
domain facade
  ↓
backend service
  ↓
BFF route
  ↓
frontend client

Desktop 更新导致故障时

1. 在 modules.map.ts 中找出与症状对应的 feature。
2. 在 rpcMap.ts 检查当前 RPC/path/Backend 对应关系。
3. 用 tools 的 version/unpack/find-native/delta 取得 Desktop 当前值。
4. 区分只是 transport 改动，还是 RPC signature/E2EE flow 也发生变化。
5. 按 Protocol 单体 → Backend integration → UI 的顺序验证。

@evex/linejs 的名称可能作为比较线索保留在字典中，但 Vyline Protocol 在 runtime 不依赖它。