LINE Protocol & E2EE

The current structure of @vyline/protocol, which owns communication with LINE.

Device mode

Inside Protocol

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

@vyline/protocol is not a thin HTTP wrapper. It owns device identity, login RPC, transport headers and paths, Letter Sealing E2EE, TalkService, Desktop-version tracking, and the domain facade exposed to Backend.

Login

QR

loginWithQR → protocol stack → secure QR login. Desktop modes patch systemName/modelName to match the selected device identity.

Email + E2EE

1. Fetch the RSA key.
2. Run loginV2 / E2EE confirmation.
3. Fetch the keychain.
4. Persist the local identity key.
5. Reconcile it with the latest server-side key state.

Token

After loginWithToken restores an access token, Protocol still validates the transport profile and E2EE identity.

Transport

Protocol builds user-agent, x-line-application, locale, hosts, and RPC paths from observed Desktop data. Profile resolution order is: running Desktop extraction → installed-version/OS synthesis → cache → fallback.

Paths are not selected by guessing an endpoint that looks plausible. Protocol patches and the RPC dictionary are matched against Desktop evidence. If a Desktop update may have changed a header or path, start from modules.map.ts and trace the related binary/string evidence.

E2EE

Older history can remain undecryptable if the local identity key that was used at the time is no longer available. Sending also requires the private key corresponding to the server's current keyId; missing state can result in sender-key update errors.

Receiving

1. Receive message operations through Talk sync.
2. Determine from message metadata whether the payload uses E2EE.
3. Resolve the required self, peer, or group keys and decrypt the Letter Sealing payload.
4. Normalize the result into a UI-facing message in Backend and persist it to the account-specific SQLite database.

Sending

1. Check the destination and current E2EE key state.
2. Warm or refresh the group/public key state when necessary.
3. Encrypt text or media metadata and send through the Talk/OBS path.
4. If LINE requests a sender-key update, refresh key state and retry only through the permitted retry path.

Media content is not carried entirely inside the Talk message; object storage is also involved. The Protocol RPC dictionary includes the corresponding E2EE media upload/download operations, while Backend lineService coordinates message metadata and binary handling.

Talk sync

Backend clientManager continuously fetches operations through base.talk.sync on a logged-in Protocol client. Operations are passed to lineService.processFetchedOperations for decryption, persistence, and insertion into the Frontend event buffer.

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

Domain facade

wrapSession(client) wraps a logged-in client and exposes Profile / Contacts / Chat / Talk as feature-level APIs to Backend. This boundary keeps raw Protocol RPC calls from spreading through the rest of Backend.

Modules Map and RPC dictionary

src/modules.map.ts maps features to source files, Desktop binaries, search strings, analysis documents, and recheck priorities. Current feature entries cover QR/email login, transport, E2EE key/send/decrypt, Talk send, profiles, chat administration, sync, stickers, calls, and related areas.

src/dictionary/rpcMap.ts maps each RPC's canonical name, Desktop evidence, path, stack API, domain API, Backend API, category, and notes. For new work, follow the chain below instead of skipping layers.

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

When a Desktop update breaks something

1. Identify the feature matching the symptom in modules.map.ts.
2. Check the current RPC/path/Backend mapping in rpcMap.ts.
3. Use the version, unpack, find-native, and delta tools to collect the current Desktop values.
4. Separate a transport-only change from a change to an RPC signature or E2EE flow.
5. Verify Protocol first, then Backend integration, then the UI.

@evex/linejs names may remain in the dictionary as comparison hints, but Vyline's Protocol implementation has no runtime dependency on it.