Expand description
Session persistence types and storage backends for ferogram.
This crate is part of ferogram, an async Rust MTProto client built by Ankit Chaubey.
- Channel: t.me/Ferogram
- Chat: t.me/FerogramChat
Most users do not use this crate directly. The ferogram crate wires it up
automatically when you call Client::builder().session(...) or
.session_string(...).
§What’s in here
PersistedSession: the serializable session struct. Holds the DC table (oneAuthKey+ salt + time offset per DC), update sequence counters (PTS, QTS, date, seq), and the peer access-hash cache.SessionBackend: the trait all backends implement. A single method:save(&PersistedSession)andload() -> Option<PersistedSession>.BinaryFileBackend: stores the session as a binary file on disk. Good for bots and scripts. No extra dependencies.InMemoryBackend: keeps everything in memory. Nothing survives process exit. Used for tests and ephemeral tasks.StringSessionBackend: serializes the session to a base64 string. Useful for serverless environments where you store state in an env var or database column. Load it withClient::builder().session_string(s).SqliteBackend: SQLite-backed storage via rusqlite. Behind thesqlite-sessionfeature flag. Good for local multi-account tooling.- [
LibSqlBackend]: libSQL / Turso backend. Behindlibsql-session. For distributed or edge-hosted session storage.
You can also implement SessionBackend yourself for Redis, PostgreSQL, or
anything else.
§Binary format
The file backends start with a version byte:
0x01: legacy (DC table only, no update state or peer cache).0x02: current (DC table + update state + peer cache).
load() handles both. save() always writes v2.
§Example: export and re-import a session
// Export
let s = client.export_session_string().await?;
// Later, in another process or after a restart:
let (client, _) = ferogram::Client::builder()
.api_id(12345)
.api_hash("api_hash")
.session_string(s)
.connect()
.await?;Structs§
- Binary
File Backend - Stores the session in a compact binary file (v2 format).
- Cached
MinPeer - A min-user context entry: the user was seen with
min=true(access_hash not usable directly) so we store the peer+message where they appeared so thatInputPeerUserFromMessagecan be constructed on restart. - Cached
Peer - A cached access-hash entry so that the peer can be addressed across restarts without re-resolving it from Telegram.
- DcEntry
- One entry in the DC address table.
- DcFlags
- Per-DC option flags.
- InMemory
Backend - Ephemeral in-process session: nothing persisted to disk.
- Persisted
Session - Everything that needs to survive a process restart.
- Sqlite
Backend sqlite-session - SQLite-backed session (via
rusqlite). - String
Session Backend - Portable base64 string session backend.
- Updates
State Snap - Snapshot of the MTProto update-sequence state that we persist so that
catch_up: truecan callupdates.getDifferencewith the pre-shutdown pts.
Enums§
- Update
State Change - A single update-sequence change, applied via
SessionBackend::apply_update_state.
Traits§
- Session
Backend - Synchronous snapshot backend: saves and loads the full session at once.
Functions§
- default_
dc_ addresses - Bootstrap DC address table (fallback if GetConfig fails).