v0.2.0

Added

• tg chats sync <chat> turns background sync on for a chat the default
  policy leaves out, such as a large group or a channel; --off stops its
  catch-up and history and --auto goes back to the policy. The choice
  survives daemon restarts. Messages that arrive live are cached in every
  chat, whatever its mode.
  The chat is found in the cache by @username, by the ID tg chats list
  shows or by a marked ID, without Telegram credentials; for a chat that
  isn't cached yet it suggests starting the daemon or running tg chats get.
  While the daemon writes the cache, the command waits for the write lock
  instead of failing. Running it again with the chat's mode on a chat whose
  sync jobs failed deletes them, so the daemon retries them at its next
  refresh.
  A chat you haven't joined, such as a public channel, gets new messages on
  daemon start and after reconnects.
• tg messages list --chat <peer> reads a chat's history newest first and
  pages it with --before and --after (--limit, --includeDeleted). It
  is cache-first: the cache answers a window only when it holds all of it
  without a gap, otherwise or with --fresh Telegram does, and fetched pages
  are cached. Items are the same as in tg messages search.
• tg messages get --chat <peer> --id <id> [--context N] returns one message
  with up to N messages on each side, cache-first, --fresh to fetch. A
  context side the cache doesn't hold whole comes from Telegram, and if
  Telegram can't be asked, a cached message comes back with the context the
  cache holds.
• The cache records the message ID ranges of each chat that it holds without
  a gap, in the new history_ranges table, which tg sql print-schema
  describes. Every page the daemon or tg messages list and get cache adds
  one, so reads can't run across messages the cache lacks.

Changed

• Forward catch-up runs only for chats that are behind: on start and after
  reconnects, for chats whose newest message in the dialog list is above the
  cursor, and until a gap is closed. It no longer polls every enabled chat
  every 30 seconds. The first catch-up after a restart or reconnect fetches the
  messages received live since the last one again.
• Sync jobs run in three lanes that take turns: catch-up gets half the jobs,
  first pages and history a quarter each, and an idle lane's turn goes to the
  others. Inside a lane, small chats go first. History starts right after a
  chat's first page, and works for every enabled chat, not only small ones.
• The daemon's dialog pass also lists archived chats, so they are cached and
  sync jobs can reach them. The pass doesn't start syncing them: an archived
  chat starts when a message arrives in it live or when tg chats sync turns
  it on.
• Groups whose member count Telegram doesn't report are off by default, like
  groups over 100 members, instead of getting a full-history sync. The daemon
  keeps the last known count when a dialog leaves it out.
• History backfill for a chat without a forward or backward cursor starts at
  the newest page instead of below the oldest cached message, so pages that
  tg send or tg messages list and get cache can't make it skip a gap or
  mark a chat's history complete early.

Fixed

• History backfill and first pages never ran on accounts with more than a few
  dozen chats, because catch-up for every chat always went first (#6).
• A chat whose first message arrived live never got its first page, so it had
  no cursors and no history. Every enabled chat without a forward cursor now
  gets one, and the daemon caches such a chat from the message, so the first
  page of a new DM or group works before the next dialog pass.
• An empty chat was marked complete without a cursor and never caught up. Its
  cursors now start at 0, so its first message is caught up like any other.
• The first page and history pages counted messages that were already cached.
  A page of only deleted messages set the backward cursor past every message,
  or in history left it in place, so the same page was fetched forever.
• On a cache from 0.1.4 or earlier, a chat with a forward cursor but no
  backward cursor would start history below its oldest cached message, so the
  messages between that one and the cursor were never fetched, yet history
  ended up marked complete. History now pages down from the forward cursor.
• A CLI command that writes the cache (for example tg send or
  tg chats list --fresh) failed with "database is locked" if the daemon was
  writing at that moment. It now waits up to 5 seconds for the lock.
• tg send --to accepts the marked chat IDs that tg messages search and
  tg sql print (-100… for channels and supergroups, -N for basic
  groups), and a cached 10-digit user or chat ID is no longer looked up as a
  phone number.
• tg send --to +<phone> reported a rate limit on the phone lookup as a
  number it couldn't resolve. It now fails with RATE_LIMITED.
• A FLOOD_WAIT too long for the client to wait out failed a command with
  TELEGRAM_ERROR; only later calls to the blocked method got
  RATE_LIMITED. Every command that calls Telegram now reports it as
  RATE_LIMITED with wait_seconds right away.
• tg send --to <user ID> resolves a user the cache knows without an access
  hash, or whose private chat has cached messages, as that user. Before, a
  short ID became the basic group with the same number and a 10-digit one a
  phone number. Users found by @username or phone are cached, so the next
  lookup by ID needs no API call.
• tg send --to rejects a malformed number such as -12.5, 1e1 or 12.0
  instead of reading its leading digits as a basic group ID.
• tg send --to '+1 (555) 000-0000', or a + number with spaces or dashes,
  looked the number up as a username. A + now always means a phone number.
• Failed sync jobs retry with backoff (1, 2, 4 and 8 minutes) and fail after
  five attempts. A FLOOD_WAIT delays the job instead of failing it, and a
  permanent error, such as CHANNEL_PRIVATE or a chat without an InputPeer,
  fails it at once. Before, the next refresh queued a failed chat again every
  30 seconds forever and left a failed row each time. Failed rows are now
  cleaned up after 24 hours or on a daemon restart, and the chat is tried
  again then. A job whose chat is turned off while it runs is dropped if it
  fails (#9).
• tg status counts failed sync jobs (failed_jobs was always 0) and lists
  the newest ones with their attempts, error and chat mode (sync_mode), and
  the pretty output prints the tg chats sync command that retries each
  chat's failed jobs without changing its mode. It also counts the jobs
  waiting for a retry (retrying_jobs) and shows when they run again.