14 Commits

Author	SHA1	Message	Date
Ilia Denisov	fc1715128e	fix(telegram): reopen a deleted support topic instead of losing it to General ... Telegram silently routes a copyMessage aimed at a deleted forum topic into the chat's General topic with NO error, so the bot's error-based recreate never fired — the user's next message landed in General with no card. Confirmed against the prod bot logs: a relay after a topic deletion logged neither "relay to topic failed" nor "topic gone, reopening". Probe topic liveness before reusing it: re-applying the info card's reply markup is a no-op that errors only when the card (hence the topic) is gone, so the bot detects the deletion and reopens the topic + card rather than relying on the (absent) copy error. The post-copy recreate stays as a race backstop.	2026-06-23 18:45:39 +02:00
Ilia Denisov	bb18dc362b	fix(telegram): support card — text_mention name, no command/dead link ... The topic info card built the profile link as `tg://user?id=`, which clients render as dead text for a user they don't already know (the test-vs-prod difference an operator saw), and it put the raw display name through HTML — so a name starting with "/" was auto-detected as a tappable bot command that fired when tapped. Render the card with message entities instead: the display name is covered by a `text_mention` entity (the reliable way to mention a username-less user the bot has already seen — it messaged the bot), which links the profile AND, because the name sits inside an entity, suppresses the "/command" and "@mention" auto-detection on it. Drop the HTML parse mode and the tg:// link. Entity offsets are UTF-16.	2026-06-23 18:33:14 +02:00
Ilia Denisov	6a602aefae	feat(telegram): bot support relay — per-user forum topics ... Users who DM the bot anything but /start are relayed into a private forum supergroup, one topic per user. Operators (the chat's admins) reply in the topic and the bot copies it back to the user; an info card opening each topic carries a Block/Unblock toggle and a Clear button. State is a small JSON file on a new /data volume — the bot host has no database. Off by default (TELEGRAM_SUPPORT_CHAT_ID=0): the prod bot is unchanged until the operator sets the chat id and adds the bot as a forum admin. - internal/support: concurrency-safe JSON store (topic map, block list, relayed message ids) with field-targeted mutators and atomic save - bot/support.go: relay both ways via copyMessage, short-TTL admin cache, callback buttons, per-user topic-create lock, loop guard (skip the bot's own posts), reopen a deleted topic on the next message - config + compose + CI/prod-deploy: TELEGRAM_SUPPORT_CHAT_ID per contour + TELEGRAM_SUPPORT_STATE_DIR; bot-state named volume; /data pre-owned by UID 65532 so a fresh volume is writable under distroless - docs: ARCHITECTURE §15 + decision record, FUNCTIONAL (+ru), README	2026-06-23 17:47:00 +02:00
Ilia Denisov	aa330b726e	feat(telegram): localized /start welcome with channel & chat follow links ... The main bot answered /start with a single English line ("Tap to open Scrabble."). Localize it: Russian or English by the sender's reported Telegram language (Message.from.language_code, which the Bot API carries on the message itself — there is no separate user-update event — English fallback), with the longer welcome copy and a localized launch button ("Открыть «Эрудит»" / "Open “Erudite”"). The welcome links the game channel and the discussion chat by their public @username, resolved once at startup from the configured TELEGRAM_GAME_CHANNEL_ID / TELEGRAM_CHAT_ID via getChat and cached. A handle that is unset, private, or unreadable degrades to a generic noun ("the channel" / "our chat") rather than a dangling "@", so the paragraph always reads cleanly (the bot's info screen still lists the real links). Adds GameChannelID to bot.Config (wired from the existing config) for the channel handle. Tests: startText localization + handle embedding + per-slot generic fallback; handleStart language selection; resolveWelcomeHandles. README updated.	2026-06-22 19:39:00 +02:00
Ilia Denisov	c494da553a	fix(telegram): reply to /start only in private chats ... The main bot is now an admin in the moderated discussion group and receives its messages (allowed_updates includes message). Its default handler replied to every message with a Mini App launch button — an inline web_app button, which Telegram permits only in private chats — so replying in the group failed with BUTTON_TYPE_INVALID (silently: the send fails, no user-facing error). Reply only in a private chat; in the group the bot only manages permissions. The promo bot gets the same guard.	2026-06-21 17:28:01 +02:00
Ilia Denisov	1ba789a1f1	docs(telegram): invert chat-gate strategy in docs; tune logs; i18n text ... - Bake the final default-allow + mute-the-ineligible strategy into docs/ARCHITECTURE.md, docs/FUNCTIONAL.md (+_ru), platform/telegram/README.md, the deploy compose comment and the PRERELEASE tracker. The live test proved a per-user grant cannot exceed a deny-by-default group (Telegram intersects the chat default with the per-user permission), so the chat allows sending by default and the bot restricts the ineligible instead of granting the eligible. - Lower the per-event chat_member trace and eligibility evaluation to Debug; keep the actual mute/unmute actions, the startup self-check and warnings at Info, so prod logs only what the bot did. - Update game.searchingForOpponent (Searching -> Waiting for opponent / Поиск -> Ждём соперника) and the quickmatch e2e assertions to match.	2026-06-21 17:15:10 +02:00
Ilia Denisov	bdd1cc7d85	fix(telegram): invert the chat gate — mute the ineligible (default-allow) ... Telegram intersects the chat default with each user's permissions, so a per-user grant can never exceed a deny-by-default group: the original default-deny + grant design could not let any user write (can_send=true was AND-ed with the denying default). Invert it — the chat allows sending by default and the bot MUTES an ineligible member (unregistered, admin-suspended, or chat_muted) and restores an eligible one it had muted, acting only when the current state differs (idempotent, no self-loop). The block/unblock/chat_muted/registration path already sets can_send to the eligibility, so it is unchanged.	2026-06-21 16:50:44 +02:00
Ilia Denisov	0ab1719ee9	fix(telegram): grant in-chat members regardless of reported can_send ... The CanSendMessages loop-guard skipped exactly the stuck case — a restricted member whose chat_member event reports can_send=true yet who cannot actually write. Replace it with a precise loop guard (skip only the bot's own restrict action, i.e. the update whose performer is the bot) and grant any eligible in-chat member (member or restricted) otherwise. Also log the new member's can_send, is_member and the actor id for full visibility.	2026-06-21 16:25:57 +02:00
Ilia Denisov	380f82438c	fix(telegram): grant write to restricted members in default-deny chats ... A default-deny discussion group reports a present or freshly joined member as `restricted` (no send right), not `member`. The join filter required `member`, so the real case never matched and a registered user stayed muted. Grant any eligible in-chat member (member or restricted) that still lacks the send right, with a loop guard (skip when send is already allowed) so the bot's own grant does not re-fire. Revoking a now-ineligible user stays the chat-gate path's job, so this never fights a chat_muted/block.	2026-06-21 16:12:58 +02:00
Ilia Denisov	a404513037	feat(telegram): chat-gate observability + grant on first registration ... Two follow-ups from a contour test where a user joined the chat, then registered, and got no write access — with silent logs. Observability: log every chat_member update (chat id, configured id, user, old->new status), the eligibility result and the grant outcome; plus a startup self-check that warns loudly when the bot is not an administrator in the chat with the restrict-members ("Ban users") right — the common misconfiguration, previously invisible in the logs. Grant on first registration: a user who joins the moderated chat BEFORE registering is covered by no chat_member event, so the join-time grant never fires for them. ProvisionTelegram now reports first contact, and the Telegram auth handler emits chat_access_changed on it, so the gateway re-evaluates and grants write access if the user is already in the chat.	2026-06-21 15:19:21 +02:00
Ilia Denisov	e71e40eef5	feat(telegram): promo bot + channel-chat moderation gate ... Add a second standalone promo bot to the bot container (answers /start with a localized message + a URL button into the main bot's Mini App) and gate write access in a channel's linked discussion chat: grant on join when the Telegram user is registered and neither admin-suspended nor holding a new chat_muted role, and revoke/grant on the matching moderation change for a member currently in the chat. Eligibility (registered AND NOT suspended AND NOT chat_muted; the game suspension dominates) is resolved once in the backend and reached two ways: the bot's join-time unary ResolveChatEligibility over the existing mTLS bot-link, and a backend chat_access_changed event -> gateway -> ChatGate command (idempotent; a temporary-block-expiry sweeper may over-emit). The bot guards the block/unblock path with getChatMember, since bots cannot list members. A web_app button cannot open another bot's Mini App (it signs initData with the sending bot's token), so the promo button is a t.me ?startapp URL reusing the UI's VITE_TELEGRAM_LINK. The bot must be a chat admin with the restrict-members right and chat_member in its allowed updates. No schema change: chat_muted reuses the data-driven account_roles table.	2026-06-21 14:46:51 +02:00
Ilia Denisov	6aeb529f13	feat(telegram): split connector into home validator + remote bot ... Move all Telegram egress off the main host. The single connector held the bot token, long-polled Telegram and answered the gateway/backend over the trusted internal network, so the whole component (including login validation) shared fate with its VPN sidecar. Split it into two binaries that share the token: - cmd/validator (home, no VPN): Mini App initData + Login Widget HMAC only, never calls the Bot API. The gateway dials it for Telegram auth, so game login is now independent of Telegram reachability. - cmd/bot (remote): Bot API long-poll + sendMessage, the only component reaching Telegram. It holds no inbound port — it dials the gateway over a new reverse mTLS bot-link (pkg/proto/botlink/v1) and executes the send commands the gateway pushes. The gateway funnels sends to the bot-link: out-of-app push is fire-and-forget (at-most-once, dropped if no bot is connected); the backend admin broadcasts reach a gateway-served relay that forwards them and awaits the bot's ack (SendToUser/SendToGameChannel contract preserved). mTLS (pkg/mtls) is the one inter-service link that leaves the trusted segment; validator<->gateway and the relay stay plaintext internal. The bot is Telegram-rate-limited. One bot now; the gateway bot registry, an owns_updates flag and per-command ids leave seams for N later. Webhook rejected (one URL per token, adds inbound + a static address). The unified test contour runs the split (the bot keeps its VPN sidecar and dials the gateway by its internal name; bot-link certs from deploy/gen-certs.sh, generated in CI). The prod wiring — the bot on a separate host (no VPN), the gateway bot-link port published, PROD_ certs with scheduled rotation, an SSH deploy of both hosts together — is the deferred final stage (PRERELEASE.md TX, Stage 18). Docs: ARCHITECTURE, PRERELEASE (phase TX), platform/telegram + gateway + backend + deploy READMEs, FUNCTIONAL(+ru), CLAUDE.md, .env.example.	2026-06-21 00:19:07 +02:00
Ilia Denisov	0ea35fe991	Stage 16: connector test-env via UseTestEnvironment; pin it in the test contour ... - bot.New now selects Telegram's test environment with the library's native tgbot.UseTestEnvironment() instead of a token += "/test" hack (functionally identical URL /bot<token>/test/METHOD, but idiomatic) + a bot test asserting the getMe path for both test and prod. - ci.yaml pins TELEGRAM_TEST_ENV=true for the test contour (it IS the test environment) instead of a TEST_TELEGRAM_TEST_ENV variable: removes the confusing double-TEST, telegram-specific, prefixed operator knob and the secret-vs-variable footgun. Prod (Stage 17) leaves it false. - deploy/README.md + PLAN.md updated.	2026-06-05 16:44:10 +02:00
Ilia Denisov	cf66ed7e26	Stage 9: Telegram integration (connector side-service, Mini App, out-of-app push) ... New platform/telegram connector (own container, bot token only there): - go-telegram/bot long-poll loop: /start deep-links + Mini App launch button. - gRPC API pkg/proto/telegram/v1 (Telegram service): ValidateInitData, Notify (renders a localized message + deep-link button), SendToUser/SendToGameChannel (admin, wired in Stage 10). Generic methods are platform-agnostic (external_id). - Bot API base override for Telegram's test environment; Dockerfile + compose (VPN sidecar, no public ingress); README. Gateway: - initData validation relocated from the gateway into the connector; the gateway calls ValidateInitData over gRPC (GATEWAY_CONNECTOR_ADDR), drops the bot token, and deletes internal/auth. - Out-of-app push: runPushPump routes events whose recipient has no live in-app stream to connector.Notify, gated by /internal/push-target + the in-app-only flag (race-free de-dup); HasSubscribers added to the push hub. Backend: - Migration 00007 accounts.notifications_in_app_only (default true) + jetgen. - ProvisionTelegram seeds a new account's language/display name from the launch fields; IdentityExternalID reverse lookup; /internal/push-target handler. UI: - Telegram Mini App launch: detect initData, apply themeParams, authTelegram, route the deep-link start_param (g/i/f); /telegram/ guard redirects outside Telegram. Vite relative base + telegram-web-app.js. In-app-only profile toggle; share-to-Telegram link for a friend code. Vitest + Playwright coverage. Wire/docs/CI: fbs Profile/UpdateProfileRequest gain notifications_in_app_only (Go + TS); go.work uses ./platform/telegram; go-unit.yaml covers it; PLAN, ARCHITECTURE, FUNCTIONAL (+ru), UI_DESIGN, READMEs updated.	2026-06-04 07:10:21 +02:00