FAQ & technical glossary

A self-hosted platform that watches Telegram chats you authorize and republishes what they post to the chats you choose, after cleaning, filtering, templating and optionally rewriting the content.

Yes — MIT licensed, no subscription, no telemetry. You pay for the server you run it on and nothing else.

No. It reads through a Telegram user session, so any channel or group your account can see is a valid source.

A Telegram bot control panel, a web dashboard, a Flutter mobile app and the REST API — all four are checked against each other for capability parity.

The status board is generated from the repository own feature catalog on every build, and lists each capability as implemented, partial or planned with the entry points behind it. Nothing is presented as done unless the catalog says so.

atf system upgrade pulls, rebuilds through the gated path and verifies the stack. atf validate --strict tells you whether the configuration is still valid before you deploy.

You do not create a password. Open the bot, ask it for the dashboard, and it mints a single-use login code and gives you the link. Opening the link exchanges the code for a session exactly once.

Ten minutes, once. The code is random, stored only as a SHA-256 hash, and burned in the same database update that matches it — two tabs racing one link produce exactly one session.

A mint cooldown protects the link that is already live: a repeat request answers HTTP 429 with a Retry-After header and the previous unused link keeps working. Wait for the cooldown rather than expecting a new code.

No. The exchange endpoint accepts only the code — never a user id — because a Telegram id is public and accepting one unauthenticated would let any caller sign in as any account. A missing code is refused with LOGIN_CODE_REQUIRED.

The client asks for a fresh dashboard link instead of looping: GET /api/auth/bot-login-link issues a new single-use code for the caller own verified identity and surfaces the bot once, in your language.

A bearer JWT for the authenticated control plane, or Telegram Mini App initData at POST /api/auth/tma. Service-health routes are the only public ones. Details and curl examples are on the API authentication page.

Yes. Sources and targets are lists on a single task: M sources to N targets. The primary source and primary target are derived from those lists, so the simple case behaves exactly as before.

Per task. The content policy — cleaning, filters, replacements, header, footer and the AI toggle — lives on the task itself and is stored in metadata, so adding a setting never requires a schema migration.

Yes: atf rules simulate --text "…" in the terminal, POST /api/simulate over HTTP, or the browser playground for the cleaner and templates.

Copy mode republishes the content as your own message, so no "Forwarded from" banner appears. Direct forward keeps the attribution. Both are per task.

It can, per task, with your provider, model and prompts. Without an AI configuration the pipeline is unchanged — and a provider outage never blocks delivery.

Yes. Edited posts update their delivered copies within the edit window, and a reply to a message that was not forwarded is skipped rather than posted as an orphan.

Yes. When Telegram refuses a native forward (ChatForwardsRestricted), the pipeline downloads the media and re-uploads it as a fresh message instead of giving up.

The affected account is marked time-limited, its deliveries pause, the jobs stay queued, and everything resumes when the restriction expires. Nothing is dropped and nothing is retried into a ban.

Album fragments are grouped inside a short debounce window and delivered as one atomic album, so a photo set never arrives as five separate posts.

Yes — bursts are serialized per task so messages arrive in the order they were posted, even when several workers are draining the queue.

All of them: 12 classes, from text with formatting entities through albums, polls, video notes and protected media.

No. Every read and write is scoped server-side to the authenticated numeric Telegram user id, and a mismatch fails closed. An account that has not linked Telegram resolves to id 0 and therefore owns nothing.

API keys and session strings are encrypted at rest with AES-256-GCM; passwords are hashed with PBKDF2-SHA256 and 240 000 iterations. The environment contract endpoint reports whether a key is set, never its value.

Only what you configure: Telegram itself, and your AI provider if you enable rewriting. There is no telemetry or phone-home.

Static analysis reports pre-existing findings in the backup export helper. They are known and tracked, they do not cross tenant boundaries, and you should review that path before handling third-party data. See the security page for the full list of known limits.

atf status prints a live board with ports and reachability; atf doctor diagnoses deeper; GET /api/health/services reports per-service reachability and latency.

Yes. Log history is attributable — actor, service, level, subject task and correlation id — queryable from the dashboard log explorer, atf logs query, or GET /api/logs with bounded paging.

They land in the dead-letter queue with their last error. Inspect them with atf data dlq, then replay with atf data dlq --replay or POST /api/dlq/{id}/retry once the cause is fixed.

Simulate first: atf rules simulate --text "hello" shows whether the policy admits the text, then confirm the bot is an administrator in the source and the target, that the id you stored is the numeric one, and that the task is not paused. The troubleshooting runbook walks the whole tree.

Export an encrypted bundle (atf data backup-export or POST /api/backup/export), copy it, then import on the target. Configuration can be exported without secrets when you only need the shape.

Every request carries a correlation id that also appears in the log history, so an API call and the deliveries it caused can be joined in one query.