25 Commits

Author	SHA1	Message	Date
Ilia Denisov	8de9fb1ecd	feat(telegram): deny bot users at initData validation ... The validator parsed only id/username/first_name/language_code from the signed Telegram user, so a WebAppUser flagged is_bot would have been provisioned a normal account. The HMAC already proves Telegram signed the payload, so is_bot==true is Telegram itself attesting the launching principal is a bot. Parse is_bot and reject it (ErrInvalidInitData -> gateway 4xx -> launch error). A real user opening the Mini App never carries it, so this is a defensive deny. Tests cover both the denied (is_bot true) and allowed (is_bot false) paths.	2026-06-24 11:55:30 +02:00
Ilia Denisov	a4581663f4	feat(telegram): link the promo body @username to the Mini App deep link ... The promo message body now renders "@<bot>" as an HTML text_link to the same ?startapp deep link the button uses (ParseMode HTML), so tapping the mention opens the seeded Mini App instead of the bot profile. Same payload (campaign start-param, else the forwarded /start payload) backs both the button and the mention.	2026-06-23 22:40:52 +02:00
Ilia Denisov	03dfc29a54	feat(telegram): promo deep-link seeds English Scrabble for new users ... The promo bot button carries a configurable variant-seed start-param (default verudit_ru-scrabble_en). The gateway parses start_param from the validated initData and forwards it; the backend, on first contact only, seeds the new account variant_preferences from it (English Scrabble alongside the default Erudit). No schema change (the scrabble_en CHECK is already in the baseline) and the gateway<->backend REST field is additive, so the rolling deploy is safe in either order. TELEGRAM_PROMO_START_PARAM configures the payload (empty forwards the user own /start payload). Covered by account unit tests, a gateway transcode test, and an integration test asserting new-only seeding.	2026-06-23 21:51:52 +02:00
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	57c778f9b2	feat(telegram,game): single bot + per-user variant preferences ... Collapse the two per-language Telegram bots into one unified bot and replace language-based variant gating with explicit per-user variant preferences. - Telegram: one bot; drop service_language and the supported_languages set everywhere (DB, account, auth, FlatBuffers Session wire, gateway, connector proto). The single bot renders chat and out-of-app push in the recipient's preferred_language; remove the game-language push routing override (notify Intent.Language / push Event.language). - Preferences: new accounts.variant_preferences (text[], DB default {erudit_ru}, CHECK non-empty + subset of the three variants). Gates the New Game picker, vs-AI and the friend invitation the player creates, enforced server-side (HTTP 400 otherwise); an invited friend may still accept any variant. Edited on the Settings screen; variants are Erudit-first everywhere. - Admin: drop the per-bot language selectors (broadcast / send-to-user) and the feedback channel_lang column/field. - Env/CI: collapse TELEGRAM_BOT_TOKEN_{EN,RU}, TELEGRAM_GAME_CHANNEL_ID_{EN,RU}, VITE_TELEGRAM_LINK{,_EN,_RU} and VITE_TELEGRAM_GAME_CHANNEL_NAME_{EN,RU} to single unsuffixed names; drop GATEWAY_DEFAULT_SUPPORTED_LANGUAGES. - Docs updated (ARCHITECTURE, FUNCTIONAL + _ru, platform/telegram, gateway, backend, ui, UI_DESIGN, PRERELEASE). The migration squash is deferred to a follow-up PR.	2026-06-20 14:23:25 +02:00
developer	8793bd34f2	feat(stats): best-move word, moves & hint-share, and a hint-count fix (#81) ... The statistics screen gains real depth, plus a hint-count bug fix found along the way. - Best move per variant: the screen shows the actual best-move word (drawn as game tiles; a wildcard shows its letter but no value), broken down by game variant, empty variants omitted. New account_best_move table, written at game finish. - Moves & hint share: two new lifetime tiles — the player's play count and the share of plays that used a hint — from summed account_stats counters (moves, hints_used). Honest-AI games are excluded, like the rest of the stats. - Hint-count fix: the in-game hint badge no longer goes stale across games. The global wallet now rides the wire apart from the per-game allowance (wallet_balance on StateView/HintResult/StatsView), so the client reads the live wallet rather than a per-game snapshot; game_players.hints_used now counts every hint (allowance + wallet), its true per-game total. - Account merge: sums the new moves/hints_used counters and merges the per-variant best moves (higher score kept), which it previously dropped. - Admin: the user card shows Moves and Hints used. - UI polish: tab/label wording, game-over text, and e2e selectors hardened against label changes. All wire additions are trailing (backward-compatible). Docs (ARCHITECTURE, FUNCTIONAL +ru, UISN_DESIGN) updated in step.	2026-06-17 22:17:27 +00:00
Ilia Denisov	12d128f1cc	feat(nudge): name the sender; blink lobby cards; re-animate toasts ... The "waiting for your move" popup was the nudge (chat.nudge), shown without a sender name. Resolve the nudger's per-game seat name server-side and carry it on a new NudgeEvent.sender_name field, so: - the in-app toast reads "<opponent>: Waiting for your move 🤭" (chat.nudgeBy); - the out-of-app Telegram push names the sender too (render nudgeBy); falling back to the plain phrase when the name is absent (RU mirrored). The your_turn toast already named the opponent and is unchanged. Lobby: when a card transitions into "your turn" or "finished" while the lobby is open, its status emoji blinks twice (two 1s fades); the opponent's-turn change stays in place. Blink state is keyed by game id (SvelteSet + per-id nonce/timer) so overlapping events animate in isolation; suppressed under reduce-motion. Toast: a per-message seq re-keys Toast.svelte, so the freshest toast cancels the previous one and replays its entrance, uniformly on every screen. Tests: notify.Nudge round-trip + render named/fallback (Go), game.Service.SeatName (integration), codec/i18n/gamePhase/shouldBlink (UI). Docs (FUNCTIONAL +_ru, UI_DESIGN) + PLAN TODO-7 (deferred FLIP card-relocation animation) updated.	2026-06-16 19:09:24 +02:00
Ilia Denisov	8881214213	R6(a): de-stage code, docs, READMEs; split stage6_test ... Mechanical, behaviour-preserving removal of Stage N / TODO-N / phase (RN) references from comments, doc-comments, service READMEs, the current-state docs (ARCHITECTURE, FUNCTIONAL+_ru, TESTING, UI_DESIGN), config-file comments, and the .fbs/.proto schema comments. PLAN.md / PRERELEASE.md / CLAUDE.md keep the stage history. - Rename the only stage-named identifiers: registerStage8 -> registerSocialOps, registerStage11 -> registerLinkOps (gateway transcode). - Split stage6_test.go: TestEmailLoginFlow -> email_test.go, TestGuestAutoMatchLeavesNoStats (+ provisionGuest) -> account_test.go. - Regenerated proto bindings (push.pb.go, telegram_grpc.pb.go) from the de-staged .proto comments; FB Go/TS bindings unchanged (flatc strips schema comments). go build/vet/gofmt clean across modules; integration typecheck and pnpm check green.	2026-06-10 16:56:03 +02:00
Ilia Denisov	f166ff30fe	Stage 17 #4: enrich the out-of-app your-turn push + add game-over ... The Telegram 'your turn' notification now names the opponent and recaps their last move (voiced as the opponent: «{name}: my move — «WORD». Score 120:95» for a scoring play; a short 'swapped / passed, your turn' otherwise), and a new game-over notification reports the result + final score when a game ends by any path (closing play, all-pass, resign, timeout). Scores are recipient-first (the reader's score leads), 2-4 players (120:95:80). - schema: YourTurnEvent gains opponent_name/last_action/last_word/score_line (appended, backward-compatible); new GameOverEvent{result, score_line}. Go + UI bindings regenerated (flatc 23.5.26 + pnpm codegen). - backend: notify.YourTurn enriched + notify.GameOver; emitMove resolves the mover's name and emits per-recipient (your_turn to the next mover, game_over to every seat), with recipient-first score lines built in one place. - gateway: game_over joins the out-of-app whitelist (routing.go). - connector: render builds the enriched your_turn + game_over text per language (en/ru). - tests: notify round-trip (enriched + game_over), emit (enriched fields + game_over to all seats / per-seat result), connector render (en/ru), routing; integration replay (play → your_turn with real name; resign → game_over) green. - docs: ARCHITECTURE push catalog + out-of-app set, FUNCTIONAL (+ _ru), PLAN tracker.	2026-06-09 01:15:18 +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	e9f836db87	Stage 15: dual Telegram bots & language-gated variants ... Service-agnostic refinement of the owner's idea: the sign-in service returns a set of supported game languages with the user identity, and the lobby gates the New Game variant choice by it (en -> English; ru -> Russian + Эрудит). - Connector hosts two bots in one container (one per service language, each its own token + game channel; the same telegram_id spans both). ValidateInitData tries each token and returns the validating bot's service_language + supported_languages. Per-language config (TELEGRAM_BOT_TOKEN_EN/_RU, channels). - supported_languages rides the Session (fbs, session-scoped, not persisted); the UI offers only the matching variants on New Game — gating only the START of a new game (auto-match + friend invite), not accept/open/play; backend does not enforce. - service_language persisted (accounts.service_language, migration 00010, written every login, last-login-wins) and routes the user-facing Notify push back through the right bot (push-target coalesces with preferred_language). - Admin SendToUser/SendToGameChannel gain an operator-chosen language selector in the console (unrelated to ValidateInitData). - Non-Telegram logins carry the gateway default set (GATEWAY_DEFAULT_SUPPORTED_LANGUAGES, all variants). Wire (committed regen): ValidateInitDataResponse +service_language +supported_languages; Session +supported_languages; SendToUser/SendToGameChannel +language. Docs (ARCHITECTURE/FUNCTIONAL/_ru/READMEs) + PLAN updated; stage marked done.	2026-06-05 09:35:53 +02:00
Ilia Denisov	dcd8de8b00	Stage 12: observability & performance (OTel/OTLP, domain metrics, guest GC) ... - pkg/telemetry: shared OTel provider bootstrap (none/stdout/otlp + W3C propagators + Go runtime metrics); backend/internal/telemetry becomes a thin facade keeping its gin middleware. - Telemetry parity: gateway and the Telegram connector gain telemetry runtimes and config (GATEWAY_/TELEGRAM_ SERVICE_NAME + OTEL_*); otelgrpc instruments the backend push server, the gateway's backend+connector clients and the connector server. Default exporter stays none (collector/dashboards are Stage 14). - Operational metrics (variant attribute on game-scoped ones): game_replay_duration, game_move_validate_duration, games_started_total, games_abandoned_total, game_cache_active, chat_messages_total{kind}, gateway edge_request_duration. Wired via the SetMetrics setter pattern (default no-op meter). - TODO-3: account.GuestReaper deletes guests with no game seat past BACKEND_GUEST_RETENTION (default 30d, swept every BACKEND_GUEST_REAP_INTERVAL). - Tests: pkg/telemetry exporter selection; game/social/edge metric recording via a manual reader; config (otlp accepted, guest knobs); inttest guest reaper. - Docs: PLAN.md re-scopes Stage 12 and adds Stage 13 (alphabet-on-wire) + Stage 14 (CI/deploy) with the agreed dictionary-versioning resolution; ARCHITECTURE 11/13, TESTING, the three READMEs and FUNCTIONAL(+ru) updated.	2026-06-04 14:22:15 +02:00
developer	01485d8fc6	Stage 11: account linking & merge (email + Telegram Login Widget) (#12)	2026-06-04 09:18:17 +00: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