Module session 

Session ownership, authentication, and ordered update consumption.

Construct with Session::bot for a bot token, or Session::open to handle authorization yourself. Each owner exposes cloneable request-only Clients. Keep receiving application updates after authentication, and finish with Session::close. See the crate guide for setup and cleanup.

Manual authorization

Read Session::recv_auth until TDLib reports readiness. Match the generated authorization state and send the corresponding request through Client::send: for example, setAuthenticationPhoneNumber, checkAuthenticationCode, or checkAuthenticationPassword. Other states may require registration, email, device confirmation, or application-specific interaction. Consult the generated state documentation rather than assuming a fixed phone/code/password sequence.

Parameter setup has already happened when open returns, although an earlier authorizationStateWaitTdlibParameters update may still be queued. Non-auth updates encountered during authentication are buffered for later Session::recv calls. The auth stream is not a replayable state snapshot.

Session storage

Use a separate session directory for each account, and do not open one directory concurrently from multiple clients or processes. Existing authorization can be reused; changing a token does not switch the account in an authorized directory. Protect session files as credentials and configure database encryption through the generated parameters when required.

Structs

Session

The unique owner of one native TDLib session.

Functions

parameters

Builds editable TDLib parameters with local database and file directories.