TeleGap

The brief: drive real Telegram user accounts — MTProto through gramjs and @mtcute, no bot-API shortcuts — from one Next.js 15 panel with a dedicated Node.js backend.

Bird's eye: the panel never touches Telegram itself — REST + WebSocket to a Node.js backend that owns the MTProto clients, with Supabase as the single spine for sessions, budgets and queues.

Login first: phone → Telegram code → optional 2FA password → session_string in Postgres. Proxy attached, budget reset, the account is a real client that survives restarts.

The accounts view never lies: live budgets from check_rate_limit() — 50 groups per 24h, cooldowns counting down, next slot per account, flood-waited accounts parked and skipped.

Group farming shows its work: 10 s between groups, seeded starter messages, randomized Adjective_noun123 usernames — every anti-ban delay is a visible control, not a hidden constant.

Channels run the same engine with broadcast-grade naming and content protection — plus a backfill that syncs counts with the external auto-leave bot. Bots too: /newbot through BotFather itself, token captured the moment it replies.

Then the payoff — one messaging engine, two tempos. Broadcast: text or image+caption to every chat, now. Chat IDs are never stored; iterDialogs discovers them live at send time.

Drip is the patient one: one Groq call writes the whole message pool, you edit it in MessagePreview, then the scheduler spreads X messages evenly across Y days per chat — resumable, flood-aware.

Proof, side by side: the real Telegram client on the left, the panel's console on the right — every send queued on the right lands on the left, 1.5 s apart.

And the queue never loses an operation: per-account progress in messaging_targets, FLOOD_WAIT parking instead of dying, retries with next_attempt_at, everything streamed over WebSocket.

From login to drip — accounts, groups, channels, bots, broadcast — one panel runs the whole Telegram fleet while its owner sleeps.