Docs / 仕組み

LINE Protocol & E2EE

LINEとの通信を担当する @vyline/protocol の現在の構成です。

Device mode

値	位置づけ
`IOSIPAD`	既定。副端末として公式Desktop/スマホとの共存を狙う
`ANDROIDSECONDARY`	副端末代替
`DESKTOPWIN`	Desktop header/login patch。公式Windows Desktopと競合し得る
`DESKTOPMAC`	Mac Desktop相当のmode。公式Mac Desktopと同時利用を前提にしない

Protocol内部

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

@vyline/protocolは「HTTP clientの薄い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を実機identityに合わせるpatchが入ります。

Email + E2EE

RSA key取得
loginV2 / E2EE confirm
keychain取得
自己鍵を保存
server最新鍵と整合

Token

loginWithToken でaccess tokenを復元した後も、transportとE2EE identityのensureを通します。

Transport

Desktop実測情報から user-agent、x-line-application、locale、host、RPC pathを構成します。Profile解決の優先順位は、稼働中Desktopの抽出 → install/OS合成 → cache → fallbackです。

用途	主なpath	役割
Talk RPC	`/S4`	message、chat、contact、E2EE key等のTalkService系
Desktop login	`/api/v3p/rs`	`loginV2`、E2EE login confirm等
RSA key	`/api/v3/TalkService.do`	Email login前のRSA情報取得
keychain	`/LF1`	login時のE2EE keychain取得経路

pathは「それっぽいendpointを推測」して決めず、ProtocolのpatchとRPC辞書、Desktop側の証拠を対応させます。Desktop更新でheader/pathが変わった疑いがある場合はmodules.map.tsから関連binary/stringを辿ります。

E2EE

ログイン前の古い履歴は、当時と同じ自己鍵が揃わないと復号できない場合があります。また送信ではserver最新 keyId に対応する秘密鍵が必要で、欠落するとsender-key update系エラーになります。

受信

Talk syncでmessage operationを取得する。
message metadataからE2EE対象かを判定する。
自分/相手/グループの鍵を解決し、Letter Sealing payloadを復号する。
BackendでUI向けmessageへ正規化し、account別SQLiteへ保存する。

送信

送信先と最新E2EE key状態を確認する。
必要ならgroup key/public keyをwarm/refreshする。
textまたはmedia metadataを暗号化し、Talk/OBS経路へ送る。
sender key更新要求が返った場合は鍵状態を再取得し、許可された経路でretryする。

media本体はTalk messageだけで完結せずobject storage経路も使います。ProtocolのRPC辞書にはE2EE media upload/downloadの対応もあり、Backend側lineServiceがmessage metadataとbinary処理をまとめます。

Talk sync

BackendのclientManagerはlogin済みProtocol clientのbase.talk.syncを使い、operationを継続取得します。取得した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) でlogin済みClientを包み、Profile / Contacts / Chat / Talkを機能別APIとしてBackendへ提供します。Protocolの生RPCをBackend全体へ漏らさないための境界です。

Modules MapとRPC辞書

src/modules.map.ts は機能ごとの関連ファイル・Desktop binary・検索文字列・分析docs・再確認priorityを持ちます。現在はQR/Email login、transport、E2EE key/send/decrypt、Talk send、profile、chat admin、sync、stickers、calls等をfeature単位で引けます。

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更新で壊れたとき

modules.map.tsで症状に対応するfeatureを特定する。
rpcMap.tsで現在のRPC/path/Backend対応を確認する。
toolsのversion/unpack/find-native/deltaでDesktop側の現在値を採る。
transportだけの変更か、RPC signature/E2EE flowまで変わったかを切り分ける。
Protocol単体、Backend integration、UIの順に検証する。

@evex/linejsの名前は比較用の手掛かりとして辞書に残る場合がありますが、VylineのProtocol実装はそれへruntime依存しません。