Crate ferogram_session 

Session persistence types and pluggable storage backends.

Saves auth key, salt, time offset, DC table, update sequence counters, and peer access-hash cache.

Crate contents

• PersistedSession: the serializable session struct (DC table, auth keys, update counters, peer access-hash cache).
• SessionBackend: the sync snapshot trait that all backends implement.
• Built-in backends: BinaryFileBackend, InMemoryBackend, StringSessionBackend, and optionally SqliteBackend and [LibSqlBackend] behind feature flags.

Binary format versioning

Every file starts with a single version byte:

• 0x01: legacy format (DC table only, no update state or peers).
• 0x02: current format (DC table + update state + peer cache).

load() handles both. save() always writes v2.

Structs

BinaryFileBackend

Stores the session in a compact binary file (v2 format).

CachedMinPeer

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 that InputPeerUserFromMessage can be constructed on restart.

CachedPeer

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.

InMemoryBackend

Ephemeral in-process session: nothing persisted to disk.

PersistedSession

Everything that needs to survive a process restart.

SqliteBackend

SQLite-backed session (via rusqlite).

StringSessionBackend

Portable base64 string session backend.

UpdatesStateSnap

Snapshot of the MTProto update-sequence state that we persist so that catch_up: true can call updates.getDifference with the pre-shutdown pts.

Enums

UpdateStateChange

A single update-sequence change, applied via SessionBackend::apply_update_state.

Traits

SessionBackend

Synchronous snapshot backend: saves and loads the full session at once.

Functions

default_dc_addresses

Bootstrap DC address table (fallback if GetConfig fails).