Concepts
A Telegram client identity is several things at once: the storage a client keeps, the session a library holds, the profile it announces, the checks that keep the profile believable, the browser behind a web client and the crypto underneath. These pages explain each one as opentele2 models it, with the same idea shown in Python, Node and Rust.
Folders, local passcodes with Argon2id and scrypt wraps, several accounts, the key file and the MTP config; reading and writing.
Telethon strings and .session + .json pairs, mtcute v3 strings, grammers SessionData, and the
way back to tdata.
The eight official clients, Generate with a unique id, the device catalogs and web devices drawn
from browser fingerprints.
The fields a client sends, their validation, tz_offset, msg_id offsets, the layer and the seven
consistency checks.
HTTP headers and full browser fingerprints from Bayesian networks, byte-identical across languages for one seed.
What runs on the Rust core for Telethon, mtcute and grammers, and what stays in the client libraries.
The built-in versions, live versions from the release sources, Chrome and Firefox, and applying a patch.
Why the three packages give the same answers: the bindings are glue over opentele2-core.
One rule for every page
The core owns the logic, the tables, the texts, the crypto and the randomness. A binding converts values, calls the core and adapts the result to its client library. So when a page says “the same in Python, Node and Rust”, it is the same code path, checked against the same golden vectors.
tdata folders, auth keys and session strings are credentials. Never share them, never commit
them and keep them out of logs. opentele2’s own key types print key ids only, but a grammers
SessionData prints its raw keys with Debug.