tgdata 0.0.9__tar.gz → 0.1__tar.gz

{tgdata-0.0.9 → tgdata-0.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: tgdata
-Version: 0.0.9
+Version: 0.1
 Summary: A production-grade Python library for extracting and processing Telegram group and channel messages
 Author: enes kuzucu
 Classifier: Development Status :: 3 - Alpha
@@ -14,7 +14,7 @@ Classifier: Programming Language :: Python :: 3.10
 Classifier: Operating System :: OS Independent
 Requires-Python: >=3.7
 Description-Content-Type: text/markdown
-Requires-Dist: Telethon<2.0,>=1.45.0
+Requires-Dist: Telethon<2.0,>=1.45
 Requires-Dist: pandas>=1.0
 Provides-Extra: proxy
 Requires-Dist: python-socks[asyncio]>=2.0; extra == "proxy"
@@ -59,6 +59,10 @@ A production-grade Python library for extracting and processing Telegram group a
 - 🩺 **Account Health Events**: Every wait, logout, ban, restriction or lost group is reported as a plain-data event — through one callback, a log line and a per-account summary — and "ok" when it ends
 - **Per-account read budgets**: An optional shared SQLite ledger limits message pulls over a rolling 24 hours, with persistent warm-up steps and recoverable partial results
 - **Versioned message batches**: Read bounded raw snapshots with canonical JSON, replayable batch IDs, safe continuation cursors and optional content-addressed media
+- **Durable daily continuation**: Keep per-group progress and pending batches in a pluggable store, replay after restart, and advance only after explicit acknowledgment
+- **Reading worker**: Run a serial process that accepts explicit-account JSON jobs for batches, group lookup, access checks and joining, with correlated health replies
+
+- **Account routing and failover**: An optional pool chooses among distinct existing accounts, enforces their budgets and preserves daily/backfill delivery; automatic joining is excluded
 
 ## Installation
 
@@ -66,12 +70,23 @@ A production-grade Python library for extracting and processing Telegram group a
 pip install tgdata
 ```
 
+## Reading worker
 
-## Authentication
+Run `python -m tgdata.worker --config worker.json` to accept serial JSON-line
+jobs for an explicitly selected account: read a message batch, look up a group,
+check access or join. The worker reuses existing sessions, proxy/device settings
+and provisioned budgets, verifies the account for each job, and returns correlated
+results and health events. It never requests a login code or retries a lost job.
 
-tgdata supports 1 authentication at the moment. 
+See [the worker protocol and setup](docs/worker.md) for Telethon 1.45.0, inventory,
+reply/exit semantics and session-store bootstrap. Try
+`python examples/reading_worker.py --demo` for an offline process demonstration.
+Scheduling, result storage and continuation acknowledgments stay with the caller.
+
+## Authentication
 
-(2 other are being implemented)
+Use terminal login for a local first run, or the explicit `LoginFlow` API for
+an application that collects the phone, code and optional password itself.
 
 1. get telegram development credentials in telegram API Development Tools from [https://my.telegram.org/apps](https://my.telegram.org/apps)
 
@@ -118,6 +133,36 @@ prompting.
   Retrying cannot log it back in — and, unlike before, it no longer sends the
   owner a fresh login code on every retry.
 
+### Step-by-step login without console prompts
+
+`LoginFlow` lets your application supply each input in a separate call:
+
+```python
+from tgdata import LoginFlow
+
+flow = LoginFlow("config.ini")
+status = await flow.start(phone)              # Deliberately requests one code.
+status = await flow.submit_code(code)
+if status.step == "password":
+    status = await flow.submit_password(password)
+if status.step == "complete" and not status.cleanup_pending:
+    # session_name must equal the configured session_file store key.
+    store.save(session_name, flow.session_data)
+```
+
+Inspect `status` after every call: waits, expired codes and unsupported Telegram
+interactions need application handling. The flow uses the configured proxy and
+device settings and never loads or replaces an existing session automatically.
+The application saves the finished credential explicitly.
+
+You can keep the flow in memory or store `flow.export_state()` privately and
+restore it with `LoginFlow("config.ini", state=saved_state)`. Use only the latest
+state with one owner at a time. The state is secret, not a browser token; restoring
+it does not make an interrupted request safe to repeat. See the
+[login guide](docs/stepwise_login.md) for errors, cancellation, cleanup and
+session-store integration. Qualified offline against Telethon 1.45.0; live code
+delivery and password acceptance remain unqualified.
+
 ### Keeping sessions out of files
 
 Pass a store once to keep each account's session in your application's storage:
@@ -391,131 +436,84 @@ The budget suite exercises real Telethon request/iterator code with scripted
 replies on 1.45.0. It does not test live Telegram response bounds or
 whether any chosen limit prevents account restrictions.
 
-## Group lookup, access and joining
+### Joining with an account allowance
 
-These operations each open, authenticate and disconnect one short-lived client.
-They use the configured proxy, device identity and session store, never prompt
-for login, and do not change `current_group` or use the persistent client/pool.
-Log the account in first as described under Authentication. Tested with
-**Telethon 1.45.0**; the package now requires at least that version.
+`JoinBudget` provides persistent per-account policy and status for admitted join
+attempts in a rolling 24-hour window. Provision explicitly with
+`JoinBudget("allowances.sqlite3", create=True)`, then reopen without `create=True`
+in later jobs. `configure(account_id, daily_limit)` retains spent allowance;
+zero pauses admission. `status(account_id).to_dict()` returns a local snapshot.
 
-```python
-from tgdata import TgData, JoinBudget, JoinBudgetExceeded
+Pass that ledger to `TgData(config_path, join_budget=budget)` and call
+`await tg.join_group(target, account_id=expected_numeric_id)`. A temporary client
+verifies the account, resolves the target, and claims one attempt immediately before
+each new SDK join/import send. Known membership or a known payment requirement
+returns without a mutation or charge. Failed or interrupted admitted attempts are
+not refunded.
 
-budget = JoinBudget("/absolute/path/join-budgets.sqlite3")
-tg = TgData("config.ini", join_budget=budget)
+The portable result distinguishes `joined`, `already_joined`, `requested`,
+`payment_required` and `interaction_required`. Its group metadata is from preflight;
+joining does not prove history access. Payments and bot interactions are left to the
+caller. The join guard applies to this operation; raw clients remain outside it.
+See [joining and outcomes](docs/group_joining.md) and
+[the allowance contract](docs/join_budget.md) for configuration and failure behavior.
 
-# In your async function: enroll the actual account once, then keep the policy.
-async with tg.connection_engine.ephemeral_client() as client:
-    me = await client.get_me()
-budget.configure(me.id, daily_limit=3)  # Illustrative policy, not a safe rate.
+## Account routing and failover
 
-details = await tg.lookup_group("@group_handle")
-access = await tg.check_group_access("@group_handle")
-print(details.to_dict(), access.to_dict())
+Use `AccountPool` when tgdata should choose among distinct, already logged-in accounts
+for a group read. Supply account configurations, existing budget policies, canonical
+groups and persistent pool state. It supports raw batches and existing daily/backfill
+operations. Plain `TgData` connection pooling still means sessions of one account.
 
-# When your caller explicitly chooses to join:
-try:
-    result = await tg.join_group("@group_handle")
-    print(result.status, result.to_dict())
-except JoinBudgetExceeded as error:
-    print(error.status.to_dict(), error.retry_after)
+```python
+from tgdata import (
+    AccountPool, PoolAccount, PoolGroup, PoolReadCapture,
+    ReadBudget, SQLiteAccountPoolStore,
+)
 
-print((await tg.get_join_budget()).to_dict())
+pool = AccountPool(
+    [PoolAccount(111111, "account-a.ini"), PoolAccount(222222, "account-b.ini")],
+    [PoolGroup(-1001234567890, "@my_existing_group")],
+    read_budget=ReadBudget("existing-read-budgets.sqlite3"),
+    state_store=SQLiteAccountPoolStore("existing-pool.sqlite3", create=False),
+)
+capture = PoolReadCapture()  # Keep this reference outside the awaited read.
+try:
+    result = await pool.read(-1001234567890, capture=capture, after_id=500, limit=100)
+    print(result.account_id, result.batch.batch_id)
+finally:
+    snapshot = capture.snapshot()  # Available complete records also survive failure/cancellation.
+    await pool.close()
 ```
 
-`lookup_group` and `check_group_access` also work without a join budget. Accepted
-references are bare or `@` handles, `https://t.me/handle` (also `telegram.me`),
-and invite links `https://t.me/+HASH` or `https://t.me/joinchat/HASH`. Optional
-`http://`, `www.`, or a bare Telegram host are accepted. Handles use 4–32 ASCII
-letters, digits or underscores and begin with a letter. Invite hashes retain
-their case. Links with extra paths, query strings, fragments, userinfo or ports,
-phone numbers and non-Telegram URLs are rejected before opening a client.
-
-Lookup/access can also take a nonzero integer ID or its decimal string when the
-session already knows that group. A marked channel ID such as `-1000000000007`
-identifies its peer kind; a positive ID is accepted only when unambiguous among
-cached users/chats/channels. Unknown IDs do not trigger a dialog scan. Joining
-accepts handles or invite links. References resolving to users are rejected.
-
-| Operation | Result | What it establishes |
-|---|---|---|
-| `lookup_group(target)` | `GroupLookup` | Available metadata, observed `member`, whether approval/payment is indicated, and any temporary preview expiry |
-| `check_group_access(target)` | `GroupAccess` | `readable` after a successful history request, `denied` after a Telegram group-access error, or `unprobed` when no usable peer is available |
-| `join_group(target)` | `GroupJoin` | `joined`, `already_joined`, `requested`, `interaction_required`, or `payment_required` |
-
-The immutable results have `to_dict()` methods containing only JSON-ready data.
-`group` contains `id`, marked `peer_id`, `title`, `username` (without `@`), `kind`
-(`group`, `megagroup`, `channel` or `unknown`) and `participants_count`. Missing
-details are `None`: an unjoined invite preview has no invented group ID. An access
-denial during resolution can have `group=None`. Existing discovery `GroupInfo`
-objects retain their previous format.
-
-Lookup never reads history or joins. Membership can be unknown; it does not prove
-read access. Access issues one logical history request with limit1 when possible,
-including for nonmembers of public groups. Telethon may retry that request;
-each actual send is bounded and metered by an optional ReadBudget. An empty
-successful reply is still readable.
-`GroupAccess.readable` is `True`, `False` or `None`; `reason` is a safe denial name
-or `NO_PEER`. Authentication, transport, read-quota and local validation/storage
-failures raise their actual error instead of becoming a denied result. An optional
-`ReadBudget` meters this history request independently of the join allowance.
-
-Joining requires a configured `JoinBudget` and account policy, even if preflight
-finds existing membership. That observation returns `already_joined` without a
-mutation or charge. `requested` means approval was requested; `interaction_required`
-includes `bot_id` and `query_id`, without inventing a webview URL. Paid previews
-return `payment_required` without sending a join. tgdata does not pay, open a
-webview or wait for approval. Only `joined` and `already_joined` have `member=True`;
-other join outcomes have `member=None`. None of these replaces a separate read check.
-
-After a join acknowledgment, available returned details are cached locally. Missing
-details or failed optional cache writes do not turn that acknowledgment into failed
-joining; a cache failure logs its error type only. No extra lookup is required after
-the acknowledgment. An unrecognized reply raises `GroupResponseError` and retains
-the attempt charge.
-
-The join allowance has these rules:
-
-- **Unit:** one actual admitted join request. Every SDK retry costs another
-  attempt. Error replies (including already-participant or approval-requested),
-  transport loss, cancellation and crashes retain the charge. No uncertainty
-  refund is made. Preflight metadata and already-observed membership cost zero.
-- **Storage:** all processes/clients sharing an allowance must use the same
-  SQLite file on the same host. Policies are keyed by fresh authenticated account
-  ID, never a session name or cached identity. The parent directory must exist;
-  `:memory:` is rejected. Only IDs, policy limits and admission times are stored.
-  ReadBudget can share the file; its tables and units remain separate.
-- **Policy:** `configure(account_id, daily_limit)` requires explicit nonnegative
-  integer limits, preserves existing usage, and provides no default rate. Zero
-  stops new attempts. Lowering a limit does not erase prior attempts. The example
-  limit is not a claim about avoiding Telegram restrictions.
-- **Time:** each attempt expires 24 hours after admission, with no midnight reset.
-  Backward clock movement cannot restore spent capacity; forward jumps advance
-  expiry, so keep the host clock accurate. SQLite claims are atomic and no lock
-  is held while awaiting Telegram. Synchronous operations are normally short;
-  contention can block the event loop for up to the five-second busy timeout.
-- **Status:** local `budget.status(account_id)` or ephemeral
-  `await tg.get_join_budget()` returns `JoinBudgetStatus`. Without a budget the
-  latter returns `None` without connecting. Status reports `limit`, `used`,
-  `remaining`, observation/next-availability times and `retry_after` for one attempt.
-  Availability assumes no new claims/policy changes; a zero cap has no timed retry.
-- **Failures and boundary:** missing policy, exhausted allowance and storage
-  failure stop before mutation (`JoinBudgetConfigError`, `JoinBudgetExceeded`,
-  `JoinBudgetStorageError`). Configured factory clients also guard raw join calls;
-  join-bearing batches and unknown wrappers raise `UnsupportedJoinRequest`.
-  Separately constructed clients, other ledger files, direct private transport
-  use and delayed approvals are outside this local admission guarantee.
-
-Health events use the ephemeral call's fresh identity and a token-free invite
-label. Metadata and join results cannot clear a prior group read-access denial;
-a successful access read can. Local failures do not inherit unrelated Telegram
-errors from the caller. New operation requests raise flood waits immediately;
-the existing connection-authorization check keeps its usual wait behavior.
-
-`test_20_group_operations` verifies SDK dispatch, results, lifecycle, health and
-real SQLite concurrency offline with sockets blocked. It does not establish live
-Telegram acceptance or a safe joining rate.
+Pool `read`, `get_message_batch`, `sync_group` and `prepare_backfill` require a new
+`capture=` for each call, including stored replay. Its synchronous `snapshot()` returns
+immutable state and available data independently of exceptions or asyncio wrappers.
+While the call is running, its batch contains only complete records with an
+`interrupted` stop reason. Final success preserves the actual batch; errors and
+cancellation preserve the complete interrupted prefix. A snapshot is not an
+acknowledgment receipt. Ordinary `TgData` calls keep their signatures.
+
+For first provisioning, create a new pool store and explicitly call `initialize()`;
+do not recreate missing known state on restart. Completed partial batches stop failover
+so their data can be delivered first. Unknown attempts require explicit recovery.
+No eligible account raises structured `PoolUnavailable`, not empty history.
+
+The adapter requires Telethon **1.45.0**, one owning process and exclusive sessions.
+It never joins or prompts. Results describe the selected account's visible history.
+Cancellation waits for the call's owned source/storage work to settle. Closing the
+pool joins its own operation and retires clients without waiting for unrelated
+application work after that operation ends. A daily/backfill publication can still
+be running under its caller; its capture becomes final when that public call ends.
+Provider-owned interruption is a local storage error, not caller cancellation.
+Completed data remains available through the retained capture without implying a
+durable receipt. Captures are kept in memory; existing progress stores govern replay.
+Failed client retirement blocks reuse until an explicit recheck or close succeeds.
+Use synchronous `pool.drain_health_events()` for bounded passive health observations;
+AccountPool does not accept application health callbacks.
+Offline tests pass; two-account live qualification remains pending. See
+[Account pools](docs/account_pool.md) for selection, recovery and delivery contracts.
+Run the offline example with `python examples/account_pool.py --demo`.
 
 ## Quick Start
 
@@ -544,6 +542,29 @@ Outputs:
 Python Devs 10012312313
 ```
 
+### Look up a group and check access
+
+Use an expected numeric Telegram account ID for a short-lived, read-only observation:
+
+```python
+async with TgData("config.ini", interactive_login=False) as tg:
+    access = await tg.check_group_access("@example_group", account_id=123456789)
+    print(access.status)  # readable, denied, or unprobed
+    if access.lookup is not None:
+        print(access.group.title, access.member)
+```
+
+`check_group_access` includes lookup details and probes at most one message of history
+through the existing read budget. `lookup_group(target, account_id=...)` returns only
+metadata and membership hints, without reading history. Both verify the actual account,
+close their temporary client, and never log in or join. Operational failures still raise;
+`unprobed` means there was no usable peer, and `denied` means a classified Telegram refusal.
+
+Handles, supported Telegram links and deterministic numeric references are accepted.
+Numeric channel IDs need a cached access hash. Readability is distinct from membership
+and does not promise future access. See [the group-operations contract](docs/group_operations.md)
+for input rules, result fields, errors, budget costs and the known SDK cache limitation.
+
 ### Group discovery — finding groups you are not in
 
 `list_groups` shows what the account already follows. To find *new* rooms there are three
@@ -786,6 +807,108 @@ refuses cleanup may leave a private temporary file. The exact schema, limits,
 interruption rules
 and delivery protocol are in [Message batch v1](docs/message_batch_v1.md).
 
+### Daily continuation across restarts
+
+Use a progress store when tgdata should remember unfinished delivery and the last
+accepted message for each group:
+
+```python
+from tgdata import TgData, SQLiteSyncStore
+
+tg = TgData("config.ini", interactive_login=False,
+            sync_store=SQLiteSyncStore("daily-progress.sqlite3"))
+chat_id = -1001234567890  # canonical MessageBatch.chat_id
+
+# Initial setup: your existing archive's last accepted ID, or explicit 0.
+await tg.initialize_sync(chat_id, after_id=48213)
+try:
+    batch = await tg.sync_group(chat_id, limit=200)
+    if batch is not None:
+        await destination.accept(batch)  # your durable, duplicate-safe destination
+        await tg.acknowledge_sync(chat_id, batch.batch_id)
+finally:
+    await tg.close()
+```
+
+The next run replays a pending batch without contacting Telegram, or reads after
+the acknowledged position. Preparing a batch never advances progress. Matching
+repeated initialization does not reset it. `destination.accept` is your application
+function; acknowledge only after its effects and duplicate markers are committed.
+
+This first delivery supports one reader per group. Scheduling remains with the
+caller; backfill is separate and edits/deletions are not reconciled. Optional media,
+partial budget failures, custom storage and exact acknowledgment rules are covered
+in [Daily continuation](docs/daily_continuation.md). Run the local example without
+Telegram using `python examples/daily_continuation.py --demo`.
+
+### Fixed historical windows
+
+Give a historical collection its own progress store, then freeze its window at
+first enrollment:
+
+```python
+from tgdata import TgData, SQLiteSyncStore
+
+tg = TgData("config.ini", sync_store=SQLiteSyncStore("historical-progress.sqlite3"))
+try:
+    await tg.initialize_sync(chat_id, after_id=0, last_days=30)
+    batch = await tg.sync_group(chat_id, limit=200)
+    if batch is not None:
+        await destination.accept(batch)
+        await tg.acknowledge_sync(chat_id, batch.batch_id)
+finally:
+    await tg.close()
+```
+
+Repeated matching initialization reuses the saved dates. You can instead enroll
+with timezone-aware `start_date` and `end_date`; the start is included and end
+excluded. Daily and historical collections use separate stores, so their bookmarks
+stay independent. See [Fixed historical windows](docs/fixed_windows.md) for date
+limits, restart rules and direct batch reads. Scheduling and pacing remain with
+the caller.
+
+### Durable backfill runs
+
+For historical reads with pause/cancel, restart recovery, pacing and explicit delivery
+acknowledgments, configure a separate backfill progress store:
+
+```python
+from uuid import uuid4
+from tgdata import TgData, SQLiteSyncStore, BackfillStartRequest, BackfillPrepareContext
+
+tg = TgData("config.ini", interactive_login=False,
+            backfill_store=SQLiteSyncStore("backfill-progress.sqlite3"))
+request = BackfillStartRequest(
+    collection_id="archive-history", chat_id=chat_id, run_id=uuid4().hex,
+    destination_id="my-archive", pause_seconds=240, expected_predecessor=None,
+    last_days=30, batch_size=200,
+)
+# Durably retain request.to_dict() in your application before submitting it.
+try:
+    started = await tg.start_backfill(request, submission="new")
+    # Retain started.status.run.to_dict() for reopening and subsequent calls.
+    turn = await tg.prepare_backfill(BackfillPrepareContext.from_status(started.status))
+    if turn.batch is not None:
+        await destination.deliver_and_commit(turn.batch, turn.delivery)
+        await tg.acknowledge_backfill(turn.delivery)
+finally:
+    await tg.close()
+```
+
+`destination.deliver_and_commit` is your application's durable receiver, not a tgdata
+method. The full delivery reference identifies the obligation. Until acknowledged,
+preparation replays the saved batch; a local wait returns without sleeping. The caller
+schedules one source reader per group and keeps daily/backfill namespaces separate.
+Collection identity does not automatically partition a backend; custom stores can use
+separate namespaces in one database.
+
+See [Backfill runs](docs/backfill_runs.md) for all six operations, status/error meanings,
+exact retries, operator controls and recovery. Run the real SQLite receiver/restart
+example without Telegram: `python examples/backfill_runs.py --demo`. The public API
+passed offline fault tests and read-only live validation with Telethon 1.45.0, SQLite
+and the selected test receiver. Your deployment must establish its own receiver
+durability, reliable clock and single-reader ownership.
+
 ### Detecting & Downloading Media (photos / videos)
 
 Every fetched message carries media-reference columns, so you can tell whether a
@@ -939,6 +1062,9 @@ await tg.run_with_event_loop()
 
 ### Account health events
 
+This section describes the existing public read methods and `health_check()`.
+Verified temporary operations have the separate local view described below.
+
 Every time Telegram says no to an account, tgdata tells you:
 - which verdict;
 - about what — the account, one kind of request, or one group;
@@ -1042,6 +1168,56 @@ error, so both now confirm with Telegram whether the session is logged in.
   a level set on `telethon.client.users` during a call applies from the next
   call.
 
+### Health for verified account operations
+
+`tg.get_account_health(account_id)` returns this instance's local health snapshot
+for a **verified numeric account ID**, or `None` if it has not observed that account.
+The ID must be a positive integer, not a string or boolean. The call is synchronous:
+it does no connection, authentication or recovery. The returned dictionaries are
+independent copies, with the same fields as the health summary above.
+
+`lookup_group`, `check_group_access` and `join_group` populate this account-owned view. Existing
+message reads and `health_check()` still use their existing health view; the views
+are not combined. A join result does not clear an earlier history-access failure.
+
+Internally, an observation begins after a temporary client proves the expected
+account. Its event and retained state keep that numeric owner even if a cached
+identity changes later. The session name and account label are descriptive. Setup
+failures before proof remain errors to the caller, without inventing a condition
+for an unverified account. Forwarding those failures through another task or an
+exception wrapper preserves that neutral attribution. A separate Telegram error
+raised while handling one still reports normally; diagnostic classification of
+the original failure remains available.
+
+Owned events use **`source: "rpc"`** for an actual health-related Telegram request
+failure, including one the operation subsequently handles. Local errors and their
+causes do not create these events. Recovery is conservative: successful work from
+an operation started before a condition was recorded cannot clear it; neither can
+the call that reported it. Owned event `request` and snapshot `waiting` keys name
+the logical request with its SDK namespace, such as `messages.GetHistoryRequest`
+or `channels.GetMessagesRequest`. Transport envelopes do not change that key;
+legacy health keeps its existing request names.
+
+Waits require the matching request to succeed. A restriction requires that the
+previously refused request succeeds in a later operation with the same method.
+Another identity check cannot clear a history-read restriction. Group access
+requires explicit confirmation by the internal operation after an actual access
+result; self verification and metadata alone never imply access. The private
+[operation contract](docs/account_operations.md#owned-health-composition-stage-2)
+describes how request evidence is captured.
+
+Owned state is updated before the operation returns. Both synchronous and async
+health callbacks run in separate tasks **after the source's disconnect attempt
+finishes**. A callback may run after the result or error reaches its caller. Its
+ordinary errors or cancellation cannot change that outcome; callback re-entry is
+suppressed as above. Unequal cleanup durations can make callbacks arrive in a
+different order from the observations; use event times and the local snapshot to
+interpret state. Notification delivery is not durable or guaranteed at process
+exit. Finish ongoing operations before `await tg.close()`, which cooperatively
+cancels and awaits pending owned notifications. A callback may itself call close.
+These timing rules apply to the new owned path; the existing public health callback
+timing remains as documented above.
+
 ### Performance Tips
 
 - The client authenticates once and keeps a single **persistent connection**,
@@ -1054,7 +1230,6 @@ error, so both now confirm with Telegram whether the session is logged in.
 ## Requirements
 
 - Python 3.7+
-- Telethon 1.45.0 or newer within 1.x (verification target: 1.45.0)
 - Telegram API credentials (not bot tokens)
 - Group/channel membership