Skip to content

Browsing Chats and Message History

QenTerra edited this page Jul 29, 2026 · 1 revision

Browsing Chats and Message History

Browse combines a navigation rail, a Telegram chat sidebar, and the attachment table for one active chat.

Chat lists

Unspool maintains Telegram's main and archive lists. ChatRepository stores normalized chat summaries and orders them using TDLib list positions, with the chat ID as a stable tie-breaker.

The sidebar can render cached summaries before the first network page finishes. It then applies live updates for:

  • chat creation or replacement;
  • title changes;
  • avatar file ID changes;
  • unread count changes;
  • main and archive position changes.

Chat search is case-insensitive and filters the current normalized snapshot. Refresh asks Telegram for updated list data; it does not merge the attachment contents of different chats.

Switching chats

Selecting another chat performs a strict context transition:

  1. save the current chat's browse settings;
  2. set the new selected chat ID;
  3. restore that chat's range, filters, dates, and sort;
  4. cancel the previous scan;
  5. clear selection and its range anchor;
  6. activate only the cache keyed by the new chat ID and range.

Updates from an obsolete asynchronous scan can still be cached for their own key, but they cannot become the visible attachment list. This prevents a slow request from chat A from overwriting chat B after the user switches.

History range

The available choices are:

Choice Maximum distinct messages considered
Last 25 25
Last 50 50
Last 100 100
Last 250 250
Last 500 500
All Messages No fixed application limit

The default is Last 100. The range is available in Browse and Settings and is saved as part of each chat's browse state.

Pagination

AttachmentHistoryService requests up to 100 messages per TDLib page. For bounded ranges it requests only the remaining count, with one boundary allowance after the first page because TDLib history pagination may return the boundary message again.

The service deduplicates by Telegram message ID and attachments by AttachmentIdentity. The progress model reports:

  • distinct messages scanned;
  • a known total when the selected range is bounded;
  • attachments found so far.

Why All Messages does not stop at 100

TDLib's history total_count can be approximate, and a nonempty page can be shorter than the requested size. Therefore All Messages does not trust either condition as proof that history ended. It continues until Telegram returns an empty page or a page contributes no new message IDs.

This makes exhaustive scans correct but not instant. Large chats, network latency, Telegram availability, and rate limits determine the duration.

Cache and refresh

Completed and partial scans are keyed by (chat ID, message range). Up to 48 recent snapshots are stored locally. Opening a previously completed range can reuse that snapshot without rescanning.

Refresh invalidates the active snapshot and starts a new scan. The previous identities become a baseline so the UI can offer a “new since last scan” filter. Cancel stops the active task without assigning its future updates to another chat.

Clone this wiki locally